A forum for reverse engineering, OS internals and malware analysis 

 #28730  by flir
 Wed Jun 22, 2016 6:59 am
Hi KM Krew,

I am not really to informed about how kernel mode devices/drivers work - So yes nub (so please forgive any retard mistakes, i will try clarify if any confusion).
but recently i came across a product Symantec DataCenter Security and some of the system prevention it enables. From gathering if seems to use a agent to enforce policies on a host and then the device driver (SISIPS) seem allow/deny instruction based on the policy defined before the kernel can execute it. It works in both windows as device drivers and kernel module for unix/linux that enforces/restricts the same policies. It seems to be a rootkit from what i gather.

As anyone ever have much use with Symantec DCS? If so any thoughts?

Also, Out of curiosity, Does Windows have a device driver priority list at boot? - if the DSC device driver is a kernel driver that gets loaded at boot. If a machine is already compromised with a kernel mode rootkit, what driver takes precedes?

I do apologies if this question is retarded as the flat earth theory. Even any sort of links you recommend would be appreciative.

Thanks for your time.
 #28731  by EP_X0FF
 Wed Jun 22, 2016 7:28 am
flir wrote:Also, Out of curiosity, Does Windows have a device driver priority list at boot? - if the DSC device driver is a kernel driver that gets loaded at boot. If a machine is already compromised with a kernel mode rootkit, what driver takes precedes?
Windows driver loaded according their group order.

HKLM\SYSTEM\CurrentControlSet\Control\GroupOrderList
HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder

See LoadOdr Sysinternals tool for more info.

Windows kernel and dependencies loaded of course before drivers.

Rootkit code loaded before antimalware driver will always have advantage. Microsoft introduced ELAM for this https://msdn.microsoft.com/en-us/librar ... s.85).aspx
 #28736  by flir
 Wed Jun 22, 2016 11:31 am
Thanks for the prompt reply! i appericare it, Sorry i could provide any more technical details. But the information you provided it. Im kind of understanding out :)

from link:
ELAM drivers must be specially signed by Microsoft to ensure they are started by the Windows kernel early in the boot process. To get the signature, ELAM drivers must pass a set of certification tests to verify performance and other behavior. These tests are included in the Windows Hardware Certification Kit.
So i assume that the Symantec DSC IPS driver has passed these tests. I just wondering if a rootkit or a symantec driver would load first.

thanks for the insight tho :) have a good day/night.
 #28740  by Vrtule
 Wed Jun 22, 2016 4:47 pm
Does it really load as an ELAM driver? It would load pretty early even as a standard boot-time driver. Maybe, Symantec considers it sufficient for their purposes. Maybe, they think it would be pretty hard to bypass their driver, so they don't bother with ELAM.

If they the driver is ELAM one, it certainly passed the tests.
 #28746  by flir
 Thu Jun 23, 2016 1:14 am
thanks Vrtule, appreciate the reply.

Thinking about it, I don't think it uses ELAM... as it work cross platform from old w2k3 and Unix (which doesn't support) elam, as ELAM wasn't introduced until Win8+.
There is no documentation, nor will Symantec advise how the driver is loaded.
I've asked them, if a kernel mode driver (aka rootkit) has already compromised a machine and then they installed there DSC IPS interception driver. Which kernel driver would take priority? and does there DSC IPS interception driver protect other ring0 functions by other drivers.

I do apologises for my lack of knowledge and understand in this area of drivers/kernels and if i sound like a spazoid, i'm late to the party but i;m trying to learn what i can.

Thank you for your response.
 #28760  by Vrtule
 Thu Jun 23, 2016 10:21 pm
don't think it uses ELAM... as it work cross platform from old w2k3 and Unix (which doesn't support) elam, as ELAM wasn't introduced until Win8+.
AFAIK you enable the ELAM functionality on your driver by letting it signed by a special certificate from Microsoft. Additional signature should not be a problem for a little bit older systems (W7, maybe Vista... not sure about W2k3. But I think the only problem may arise with usage of SHA-2).

Unix also does not impose any problems with ELAM. I think they make a special binary for unix-like systems (ELF) that shares part (or most) of the code with the Windows case.
 #28768  by flir
 Sat Jun 25, 2016 4:11 am
Thanks Vrtule!
Your input and EP_X0FF has been more than i can find anywhere. I do appreciate it.
Symantec haven't really provided insight.

Sorry to sounds like a simpleton - Can a device driver (like Symantec DCS IPS) intercept and stop other device driver (rootkits) from accessing/executing in the kernel. Or Does a driver have direct access to kernel?

Long story short' - Not sure if you have experienced Symantec DSC
1. What driver takes priority to load? - this you/EP_X0FF have answered, so thank you both.
2. if a malicious rootkit was installed on machine and the Symantec DSC IPS driver was installed would the rootkit still beable to perform as normal?

As i mentioned, i apologises for my ignorance.
 #28769  by Vrtule
 Sat Jun 25, 2016 9:30 am
Sorry to sounds like a simpleton - Can a device driver (like Symantec DCS IPS) intercept and stop other device driver (rootkits) from accessing/executing in the kernel. Or Does a driver have direct access to kernel?
Well, speaking about Windows, there are documented ways how a device driver can:
* monitor/filter file system operations,
* monitor/filter registry operations,
* monitor/filter network/socket operations,
* monitor/filter accesses to processes and threads,
* monitor/filter requests targetted at any device (physical or virtual),
* and probably many more.

The driver may also do plenty of undocumented stuff (modifying data structures not protected by Patchguard, scan data structures for malicious changes...).

So, yes, a kernel driver may see what is going on in the system. So, it can see when a malicious program/driver is attempting to run/load itself and can log or block such an operation. The question is whether it is able to recognize malicious operations from nonrmal ones.

Unless the driver acts as a hypervisor, it does not have direct control over other device drivers (does not control instructions other drivers execute). Even is it does, things are IMO quite complicated since hypervisors intercept a lot of vey low-level stuff (system calls, IO instructions, interrupts...) but building an overall picture from that information might be pretty hard.

AFAIK it is not very common to control actions of another driver. That driver also runs in kernel mode so it has the same privileges as your own driver. You can try to disable the driver (for example, you know that it filters registry accesses to its registry keys, so they become invisible. You can tell the system not to send notifications about registry operations to that driver), however, the driver may detect that and may "enable" itself again.

So, fighting another driver is hard, if not impossible (in practice).

As for your second question, if a malicious rootkit is loaded prior the security one, it, in theory, always wins, since it is able to see how the security one initializes itself and may take actions to disable it.

Hope my explanations, altough not absolutely precise and correct, help you.
 #28919  by flir
 Thu Jul 21, 2016 7:26 am
Hi Vrtule,

My apologies for the late reply, i have been in the process of moving house and had no interwebs.
Thank you for the explanation! you pretty much hit the nail on the head with what i was seeking...i found my answer. So i really appreciate your insight into this topic it was been very informative, and i think it answered my original thoughts! Sorry if it was such a noob question but just having clarify from someone with more experience helped me find the information i was looking for. A regards to the question "malicious rootkit is loaded prior the security one" i thought that would be case i just wasn't sure.

Once again, sorry for not getting back to you sooner, but i did have time to ponder your information and it helped me muchly.

Thank you very much.

Ps - i'd like to thank all who contributed to this post, your insight has allowed me to find the answers i was seeking! If i could buy u all beers for your help....i totally would