I have seen and implemented DLL injection been successfully implemented on processes normally executable .exe files.I was wondering if the same is possible for and .sys / driver image file loaded into the system. For every driver file loaded into the system I inject a DLL into it which will priorly calculate the System API calls on basis of which it will be classified as a malicious or non malicious driver.
Any other possible suggestion is highly welcome!
This is truly a fool’s errand, trying to identify a driver as MALWARE is
ridiculous, once the driver is loaded all bets are off. Worse yet
trying to classify malicious behavior in a driver is going to be just
about impossible, what you define a malicious someone else will define
as normal operation, for instance I have done sequences that most user
space classifiers would define as malicious in a driver, but then I
restored the state because requirements of the environment made this
easier.
Remember that all drivers in the kernel live in the same address space
and that space contains the kernel and the DLL’s. So it is easy to
bypass any injection checking if the intent is malware.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote
in message news:xxxxx@ntdev:
> I have seen and implemented DLL injection been successfully implemented on processes normally executable .exe files.I was wondering if the same is possible for and .sys / driver image file loaded into the system. For every driver file loaded into the system I inject a DLL into it which will priorly calculate the System API calls on basis of which it will be classified as a malicious or non malicious driver.
> Any other possible suggestion is highly welcome!
xxxxx@hotmail.com wrote:
I have seen and implemented DLL injection been successfully implemented on processes normally executable .exe files.
You need to be more precise with your terms here. You do not inject a
DLL into an .exe file. Instead, you inject a DLL into a process. The
DLL’s entry point then runs, and it’s up to the DLL to decide what to do
to with the process memory. The same concept does not exist in kernel mode.
I was wondering if the same is possible for and .sys / driver image file loaded into the system. For every driver file loaded into the system I inject a DLL into it which will priorly calculate the System API calls on basis of which it will be classified as a malicious or non malicious driver.
You can’t “inject” a DLL into a driver, just like you can’t “inject” a
DLL into an executable. Injection in user mode is necessary because
every process has its own address space. In kernel mode, everything is
in one address space. Once your kernel DLL is loaded, it has access to
all of kernel memory.
Think about what you’re asking. In order to do this, you would have to
intercept every kernel API, and there are thousands of them, spread
throughout a number of drivers. That by itself would cause such a
performance slowdown that no user would ever allow it. Next, you are
assuming that you can determine statistically whether a driver is
malicious or not based on the APIs it calls. That’s utter nonsense.
What kernel APIs would you use for your statistics?
Don is 100% correct here – this is hopeless. Once you have a rogue
kernel module loaded, it’s “game over”. That rogue module could have
made shadow copies of everything you are hooking, and continue to
operate completely outside of your view.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If injecting DLL into .sys driver file is not possible how about doing the same with services.exe which loads and unloads every driver service from the system. In this manner I can scan its APIs and can prepare a suscpicion list.
Most drivers don’t alter kernel level functions by hooks, DKOMs etc. For example a rootkit manipulates ZwQueryXxx functions to conceal its activities , virus and bots manipulate ZwCreateXxx and ZwMapViewSection to inject their code. Identifying and tracking these small number of APIs will do the job.
First services.exe does not load most drivers. Second, the number of
ways that a driver can hook is close to infinite, so you will never
catch all of them. What are DKOMs? I suspect you men DCOMs which do
not work in the kernel. You talk about the kernel in ways that make me
think you have never programmed there, if you did you would realize your
approach is impossible.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote
in message news:xxxxx@ntdev:
> If injecting DLL into .sys driver file is not possible how about doing the same with services.exe which loads and unloads every driver service from the system. In this manner I can scan its APIs and can prepare a suscpicion list.
> Most drivers don’t alter kernel level functions by hooks, DKOMs etc. For example a rootkit manipulates ZwQueryXxx functions to conceal its activities , virus and bots manipulate ZwCreateXxx and ZwMapViewSection to inject their code. Identifying and tracking these small number of APIs will do the job.
I talking about targetting a specific group of drivers like those that cause buffer overflow, conceal their activities etc. I am not targetting each and every driver.
DKOM stands for direct kernel object manipulation i.e. a way of manipulating kernel level objects by a driver for a specific purpose.
If services.exe doesnot load all drivers then who else does? “svchost.exe”?
The kernel loader loads the drivers, from requests by the plug and play
manager, various kernel calls, etc. This does not count the drivers
loaded by the boot time loader (before windows is really running). Even
user space requests can bypass services.exe.
As far as drivers that cause buffer overflow that can be almost any
poorly written driver, including a lot of shipping drivers from major
manufacturers. As I stated before attempting to determine if a driver
is concealing activities is an infinitely large problem, the low hanging
fruit such as syscall hooking has been dealt with by the kernel.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote
in message news:xxxxx@ntdev:
> I talking about targetting a specific group of drivers like those that cause buffer overflow, conceal their activities etc. I am not targetting each and every driver.
> DKOM stands for direct kernel object manipulation i.e. a way of manipulating kernel level objects by a driver for a specific purpose.
> If services.exe doesnot load all drivers then who else does? “svchost.exe”?
The loader program uses service APIs for loading and unloading dynamically that is the reason why it shows “services.exe” whenever I query the process name from the hooked ZWCreateFile.
Are you talking about the loader program? I coulnot find Kernel Loader in Windows Architecture in windows internal book.
One of the many things not discussed in Windows Internals. The book is
good, but it bypasses a number of topics.
There is a component in the kernel LdrXXX that supports many of these
things. Take a look at the NtSetSystemInformation it has a documented
(incorrectly) LoadImage option as well as an undocumented capability to
load images. There is ZwLoadDriver again this does not go through
services.
Your model of how the kernel works is WRONG.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote
in message news:xxxxx@ntdev:
> The loader program uses service APIs for loading and unloading dynamically that is the reason why it shows “services.exe” whenever I query the process name from the hooked ZWCreateFile.
> Are you talking about the loader program? I coulnot find Kernel Loader in Windows Architecture in windows internal book.
I think this is about a 1001st time we see a posting that asks how to intercept malware when it’s already doing the damage.
I have the following analogy. A construction company asks: we don’t want our workers to wear hard hats, because we think they interfere with their duties. (translation: we don’t want to configure our OS deployment in a secure way). How about we build a thing that will detect when a brick hits the worker’s head, and will automatically repair the damage with epoxy and a titanium plate, and/or call 911.
>>One of the many things not discussed in Windows Internals. The book is
good, but it bypasses a number of topics.
Can you give any source or documents or weblink where I will be able to derive a proper idea of the Windows kernel? I have tried searching many wesites but almost all tell the same vague thing bypassing all important concepts.
>I think this is about a 1001st time we see a posting that asks how to intercept
malware when it’s already doing the damage.
You got my idea incorrectly. I am trying to interpret the malware behaviour the very moment it shows signs of such behaviour i.e. scanning the driver file the very time its loading request comes so that its loading request can be prempted if recognized as a malware.
Let everyone wear a helmet but take caution in every possible dangerous activity that comes along.
How on earth are you going to classify something as ‘malware’ based on the
fact that it imports from, say, ntoskrnl? Everything does. There’s nothing
exported that is intended for malware.
If you are willing to call something that does this ‘malware,’ then, no,
you’re in fact to late, because ntoskrnl/hal/whatever has already loaded,
and you’ve deemed them the source of code that can be used to create
malware. Also, you’re assuming that you can load ahead of ‘malware,’ and
stay in control, all without causing any problems.
Also, If you’re intercepting things as they try to load from disk, then by
that very definition, they have already achieved persistence, which means
you haven’t any idea of what they’ve already done.
Finally, let’s say that you’ve decided that something is ‘malware;’ what do
you plan to do about it? Fail it and have the OS BSOD? The user will not
be pleased.
It’s not that there’s necessarily NOTHING that can be done in any particular
case; it’s that you can’t know the particulars of each case when you (or
anybody else) writes code and that the problems that these types of
approaches to security cause or so very much worse than the problems which
they purport to solve.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, February 28, 2011 4:35 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL injection into sys file
>One of the many things not discussed in Windows Internals. The book is
good, but it bypasses a number of topics.
Can you give any source or documents or weblink where I will be able to
derive a proper idea of the Windows kernel? I have tried searching many
wesites but almost all tell the same vague thing bypassing all important
concepts.
>I think this is about a 1001st time we see a posting that asks how to
intercept
malware when it’s already doing the damage.
You got my idea incorrectly. I am trying to interpret the malware behaviour
the very moment it shows signs of such behaviour i.e. scanning the driver
file the very time its loading request comes so that its loading request can
be prempted if recognized as a malware.
Let everyone wear a helmet but take caution in every possible dangerous
activity that comes along.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
“You got my idea incorrectly.”
You got MY idea incorrectly. As soon the malware runs in a privileged context, the game is over. Even if you just accept the possibility the malware may have run in a privileged context, the only sane approach is salvage the data and reinstall the software.
If IT departments just stop buying those bogus “analysis and protection” tools and applied secure configurations instead, their life would get much better.
>>As soon the malware runs in a privileged context, the game is over.
That is what I am saying, and so to stop it is to prempt or block its loading request the very moment any such request comes and to do so prior classification of malware , which I have been asking , is needed before it loads and starts functioning i.e. to never allow it to function.
Secure configurations do ensure a lot of safety but not all. There will some or the other loophole which will be exploited later and when that does happen system administartor maynot even know about it. Here detection becomes important.
>Also, If you’re intercepting things as they try to load from disk, then by
that very definition, they have already achieved persistence, which means
you haven’t any idea of what they’ve already done.
Finally, let’s say that you’ve decided that something is ‘malware;’ what do
you plan to do about it? Fail it and have the OS BSOD? The user will not
be pleased.
It’s not that there’s necessarily NOTHING that can be done in any particular
case; it’s that you can’t know the particulars of each case when you (or
anybody else) writes code and that the problems that these types of
approaches to security cause or so very much worse than the problems which
they purport to solve.
I hadnot thought about the persistence problem. I was only concerned about protecting other processes from effect of the malware.
Failing a malware is not the correct approach and why will I think about it. How about giving it a quarantine as most Antiviruses do? Quarantine is much better solution until all remedies can be made. It is not always possible to reinstall the whole system every time a malware is discovered.
are you by any chance trying to create a sandbox where malwares will be
dumped and profiled? there are some very well known profilers in the market
already, and also some malware which are anti-anitimalware 
that is, those
malwares detect such sandboxes and go defunct.
typically it is said, that image or process load is too late to stop it. You
should rather fail the reading of the file from the disk.
On Tue, Mar 1, 2011 at 7:21 PM, wrote:
> >>As soon the malware runs in a privileged context, the game is over.
>
> That is what I am saying, and so to stop it is to prempt or block its
> loading request the very moment any such request comes and to do so prior
> classification of malware , which I have been asking , is needed before it
> loads and starts functioning i.e. to never allow it to function.
> Secure configurations do ensure a lot of safety but not all. There will
> some or the other loophole which will be exploited later and when that does
> happen system administartor maynot even know about it. Here detection
> becomes important.
>
> >>Also, If you’re intercepting things as they try to load from disk, then
> by
> that very definition, they have already achieved persistence, which means
> you haven’t any idea of what they’ve already done.
> Finally, let’s say that you’ve decided that something is ‘malware;’ what
> do
> you plan to do about it? Fail it and have the OS BSOD? The user will
> not
> be pleased.
> It’s not that there’s necessarily NOTHING that can be done in any
> particular
> case; it’s that you can’t know the particulars of each case when you (or
> anybody else) writes code and that the problems that these types of
> approaches to security cause or so very much worse than the problems
> which
> they purport to solve.
>
> I hadnot thought about the persistence problem. I was only concerned about
> protecting other processes from effect of the malware.
> Failing a malware is not the correct approach and why will I think about
> it. How about giving it a quarantine as most Antiviruses do? Quarantine is
> much better solution until all remedies can be made. It is not always
> possible to reinstall the whole system every time a malware is discovered.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
>>image or process load is too late to stop it. You should rather fail the reading of the file from the disk.
How to fail reading of file from the disk? You mean to say fail IRP_MJ_CREATE for the given file in question or is there any other way.
You’re going to blue screen the os in some cases if you do this.
you say u want to stop the malware from loading…but why is it loading? how
did it get into the load path? did someone create the registry keys? then u
are already compromised, is the binary in qn already in the machine? then
the machine has already been compromised…
there are attacks where the malicious payload was injected from outside the
OS through the firmware, the BIOS, or the hypervisor, waht do you do then?
you cant scan these…your best bet should be to run outside the OS and try
and protect it, like in he case of VMSafe API. x86 by design cant let u
guard pages, but this can be done from outside…Intel TXT does it.
BTW, Intel used ATP where they put the security module outside teh x86 north
and south bridge on a separate bus with a propreitary protocol and a
separate processor, so that even the interposer couldnt be used to debug it,
buti believe some one has gotten to that too (was the paper called ring -1
?)
so my friend, just blocking CREATE is not enough, you gotta find GENESIS
On Tue, Mar 1, 2011 at 10:14 PM, wrote:
> >>image or process load is too late to stop it. You should rather fail the
> reading of the file from the disk.
>
> How to fail reading of file from the disk? You mean to say fail
> IRP_MJ_CREATE for the given file in question or is there any other way.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
- amitr0
What is “suspicious”? Tell me what you are doing, and I will defeat it with
a few minutes’ thought. You could learn the same thing by statically
scanning the imports list of a .sys file, and my technique of defeating
whatever you are doing works well whether it is static or dynamic when you
do the testing.
And I don’t even write malware for a living. Or even for amusement. The
ways to defeat security, on the other hand, matter to me, and I know most of
them.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Saturday, February 26, 2011 4:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL injection into sys file
If injecting DLL into .sys driver file is not possible how about doing the
same with services.exe which loads and unloads every driver service from the
system. In this manner I can scan its APIs and can prepare a suscpicion
list.
Most drivers don’t alter kernel level functions by hooks, DKOMs etc. For
example a rootkit manipulates ZwQueryXxx functions to conceal its activities
, virus and bots manipulate ZwCreateXxx and ZwMapViewSection to inject their
code. Identifying and tracking these small number of APIs will do the job.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
One way to tell a total newbie at this is that they think that they can
actually detect this kind of behavior. The suggested approach is so naively
simplistic that I can defeat it with about 30 seconds’ thought, and probably
ten minutes of reading the DDK docs to get the details right.
Nonetheless, every newbie has to pretend that they have a clue that they can
solve this unsolvable problem. The rest of us know better. Ed Dekker and I
used to bat around ideas about how to defeat all proposed “anti-malware”
approaches just so we could have a fun mental exercise to work with.
Correct. Efficient. Robust. Pick any two. No, sorry. Pick one.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Saturday, February 26, 2011 6:51 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DLL injection into sys file
First services.exe does not load most drivers. Second, the number of
ways that a driver can hook is close to infinite, so you will never
catch all of them. What are DKOMs? I suspect you men DCOMs which do
not work in the kernel. You talk about the kernel in ways that make me
think you have never programmed there, if you did you would realize your
approach is impossible.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@hotmail.com” wrote
in message news:xxxxx@ntdev:
> If injecting DLL into .sys driver file is not possible how about doing the
same with services.exe which loads and unloads every driver service from the
system. In this manner I can scan its APIs and can prepare a suscpicion
list.
> Most drivers don’t alter kernel level functions by hooks, DKOMs etc. For
example a rootkit manipulates ZwQueryXxx functions to conceal its activities
, virus and bots manipulate ZwCreateXxx and ZwMapViewSection to inject their
code. Identifying and tracking these small number of APIs will do the job.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.