If you want to prevent code injection, run the process with higher integrity level, or in privileged context.
Hi alex, thanks, I just want to determine if it is occurring and log the event, i don’t want to prevent it.
I suggest you first need to solve Turing’s halting problem.
Thanks for that Alex, I’m looking forward to getting some usable practical answers to my question from the forum members.
xxxxx@josemorales.org wrote:
Thanks for that Alex, I’m looking forward to getting some usable practical answers to my question from the forum members.
I wouldn’t count on it. In a very real sense, Alex is right.
Look, what are the methods? You can use WriteProcessMemory directly, or
you can use a Windows hook to inject a DLL in the process and run code.
You can trap WriteProcessMemory by using something like Detours (which
injects a DLL), but what can you do about an injected DLL? EVERY
injected DLL is going to modify the memory in the process. You may be
able to learn when a DLL gets loaded into a process, but it’s not clear
you could tell whether it was a normal DLL load or an injected DLL load.
Most injected DLLs are just doing very innocent things, like mouse
trapping or keyboard hotkey checking. What do you plan to do in those
cases?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>Look, what are the methods? You can use WriteProcessMemory directly, or you can
use a Windows hook to inject a DLL in the process and run code.
You can trap WriteProcessMemory by using something like Detours (which injects a DLL),
but what can you do about an injected DLL?
Well,the most obvious answer to your question is"identify the vectors/code paths that DLL injections have to use, and monitor them". Look - the OP is not asking us whether it can be done, because he already knows the answer to this question. The only thing he asks us about is whether it can be done in some “supported” way,
Most injected DLLs are just doing very innocent things, like mouse trapping or
keyboard hotkey checking.
…or recording the keystrokes in order to try to get passowrds and other sensitive info…
Anton Bassov
> If you want to prevent code injection, run the process with higher integrity level, or in
privileged context.
You forgot to repeat your key mantras, namely, “what are you trying to do” and “never allow users to run with root privilege level” …
I suggest you first need to solve Turing’s halting problem.
This is a completely unrelated argument - it seems to be just a classical example
of “red herring” logical fallacy…
Anton Bassov
>You can trap WriteProcessMemory by using something like Detours (which injects a DLL)
The problem is to detect it in the target process, not in the calling process. Detours doesn’t help here.
currently I can suggest dll injection is occuring using a minifilter (irp_mj_create) and a driver with pssetcreateprocessnotifyroutineex and pssetloadimagenotifyroutine. If a dll is loaded into a process and that dll’s file was created by some process with a different pid then a dll injection may be occurring by one process into the memory of some other process. I can go further and determine if the inject process was created by the dll creator, if yes it may be legitimate injection, if no it may be nefarious. the assumption is when a process modifies the memory of some other process, that is suspicious. now there are other ways a process can modify some other process’s memory that this approach will not work with so I am hoping the forum here can provide a function or combination of functions that can help detect when a process is writing/modifying some other process’s memory. thanks.
xxxxx@broadcom.com wrote:
> You can trap WriteProcessMemory by using something like Detours (which injects a DLL)
The problem is to detect it in the target process, not in the calling process. Detours doesn’t help here.
Sure it does. You use Detours to trap WriteProcessMemory in ALL processes.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> You use Detours to trap WriteProcessMemory in ALL processes.
…and, at this point, the whole thing becomes reminiscent of a snake biting its own tail - you want to detect the external address space modifications ,and in order to do so, you externally modify all the processes in the system(or at least those capable of opening handles to the process of your interest with the rights to modify its memory). The true comedy will commence if there are multiple “monitors/detectors” like that running on the target system concurrently…
Anton Bassov
Hi all, thanks for these responses, I want to monitor the system and process interactions with the system to detect when one process modifies the memory space of some other process and I’d like to use kernel level api’s and functions. Any advice on which functions may help would be great, I have viewed the Mm family of functions but none of them are callback routines for process memory modification… thanks.
The bottom line is unless you know of a specific security hole in Windows, a
process modifying another process must have a handle to the process to be
modified. ObRegisterCallbacks is supposed to provide the detection of
getting that handle.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@josemorales.org
Sent: Friday, June 10, 2016 1:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting Process code Injection using MS supported
methods
Hi all, thanks for these responses, I want to monitor the system and
process interactions with the system to detect when one process modifies the
memory space of some other process and I’d like to use kernel level api’s
and functions. Any advice on which functions may help would be great, I
have viewed the Mm family of functions but none of them are callback
routines for process memory modification… thanks.
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:</http:></http:></http:>
Don
I don?t these callbacks are called when a parent process gets a handle via CreateProcess. But I expect them to be called if these handles are duplicated into a third process. The implication being that the parent has some special access ? a hold over from POSIX IMHO
I have never used this however so my assumptions might be way off
Sent from Mailhttps: for Windows 10
From: Don Burnmailto:xxxxx
Sent: June 10, 2016 1:43 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] Detecting Process code Injection using MS supported methods
The bottom line is unless you know of a specific security hole in Windows, a
process modifying another process must have a handle to the process to be
modified. ObRegisterCallbacks is supposed to provide the detection of
getting that handle.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@josemorales.org
Sent: Friday, June 10, 2016 1:33 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting Process code Injection using MS supported
methods
Hi all, thanks for these responses, I want to monitor the system and
process interactions with the system to detect when one process modifies the
memory space of some other process and I’d like to use kernel level api’s
and functions. Any advice on which functions may help would be great, I
have viewed the Mm family of functions but none of them are callback
routines for process memory modification… thanks.
—
NTDEV is sponsored by OSR
Visit the list online at:
http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at
http:
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
Thanks for that Don, i have written up some code for callbacks on process adn thread types and i log data for desired access vm-write and all access. based on that along with logged data from my minifilter I can strongly suggest a process is attempting to write to the memory of another process in these scenarios
dll injection, combo of irp_mj_create(dll), callback with vm_write/all_access, pssetloadimage with dll. I skipped some details but this does give strong indication of course the owner pid has to be the same in create and teh callback
general process writing to memory of some other process, using the callback with vm_write/all_access is the only indicator, it can be considered suspiciosu why some process would want the handle of another process with vm_write and all_access, of course there are legit reasons.
some fallbacks, general dll injection into a process where the dll is pre-exisiting does not suggest its by one process into some other process memory since there is no way to infer the “injector” pid. the above is just pointing out attempts or potential attemps, neither point out it actually happened is about to happen, in other words they do not track or intercept the actual writing of process memory.
I would appreciate if the forum members can suggest other MS supported methods that can give evidence that a process is about to write/has written to the memory space of another process. similar to ssdt hooking zwalloc,zwwritevirtual, this method perfectly detect process writing to another process memory but it is not supported.
thanks.
> …it can be considered suspiciosu why some process would want the handle of another
process with vm_write and all_access, of course there are legit reasons.
Good point…
I would suggest looking at this aspect in a more general way and to ask yourself “What is process X’s functionality if it needs to gain_any_ access to a process Y, in the first place”. To be honest, the only possible answers that get into my head are ( I assume X is not Y’s parent who gets a handle to Y simply by the virtue of calling CreateProcess())
A. Debugger (this is particularly true for VM and thread control operations)
B. Security/monitoring tools
C.Malware
OTOH, don’t forget that a “regular” Windows user process normally hosts dozens of modules.
Therefore, it may well happen that some rogue DLL has hijacked an unsuspecting process. In fact,
this is exactly the kind of experience that I recall from my “dark, miserable and unfortunate days” of being a Windows developer/user (contrary to Mr.Grig’s mantra about “never allowing users to run with root privilege level” I was getting infected on a regular basis, despite routinely running as a guest and logging in to admin account only when I absolutely had to). This is exactly what I encountered every time I noticed that my machine was sending out tons of traffic across the net…
Anton Bassov
Hi,
There is no such supported method or callback in windows kernel to detect
ntwritevirtualmemory, ntsuspendthread, ntsuspendprocess,
ntsetcontextthread, ntresume*.
If you are tracing DLL injection then consider monitoring
createthreadnotifyroutine alongside loadimage callback.
If you are tracing process hollowing on the fly in kernel, you will need to
get creative by synchronizing user and kernel mode. It’s all about how well
you dig into section objects. The resources are almost extinct.
On Jun 12, 2016 2:34 PM, wrote:
> …it can be considered suspiciosu why some process would want the handle
of another
> process with vm_write and all_access, of course there are legit reasons.
Good point…
I would suggest looking at this aspect in a more general way and to ask
yourself “What is process X’s functionality if it needs to gain_any_ access
to a process Y, in the first place”. To be honest, the only possible
answers that get into my head are ( I assume X is not Y’s parent who gets
a handle to Y simply by the virtue of calling CreateProcess())
A. Debugger (this is particularly true for VM and thread control operations)
B. Security/monitoring tools
C.Malware
OTOH, don’t forget that a “regular” Windows user process normally hosts
dozens of modules.
Therefore, it may well happen that some rogue DLL has hijacked an
unsuspecting process. In fact,
this is exactly the kind of experience that I recall from my “dark,
miserable and unfortunate days” of being a Windows developer/user (contrary
to Mr.Grig’s mantra about “never allowing users to run with root privilege
level” I was getting infected on a regular basis, despite routinely running
as a guest and logging in to admin account only when I absolutely had to).
This is exactly what I encountered every time I noticed that my machine was
sending out tons of traffic across the net…
Anton Bassov
—
NTDEV is sponsored by OSR
Visit the list online at: http:>
MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at <
http://www.osronline.com/page.cfm?name=ListServer></http:></http:>
@@ What is process X’s functionality if it needs to gain_any_ access to a
process Y, in the first place @@
That’s simply difficult to identify the motive. I believe the malicious or
suspicious activity is masked. Therefore for example, you could be
presented a doc file. You open it and it drops an exe in the background,
carries out its destructive activities while you read the doc in the
frontend.
On Jun 13, 2016 12:04 AM, “rohan kumbhar” wrote:
Hi,
There is no such supported method or callback in windows kernel to detect
ntwritevirtualmemory, ntsuspendthread, ntsuspendprocess,
ntsetcontextthread, ntresume*.
If you are tracing DLL injection then consider monitoring
createthreadnotifyroutine alongside loadimage callback.
If you are tracing process hollowing on the fly in kernel, you will need to
get creative by synchronizing user and kernel mode. It’s all about how well
you dig into section objects. The resources are almost extinct.
On Jun 12, 2016 2:34 PM, wrote:
> …it can be considered suspiciosu why some process would want the handle
of another
> process with vm_write and all_access, of course there are legit reasons.
Good point…
I would suggest looking at this aspect in a more general way and to ask
yourself “What is process X’s functionality if it needs to gain_any_ access
to a process Y, in the first place”. To be honest, the only possible
answers that get into my head are ( I assume X is not Y’s parent who gets
a handle to Y simply by the virtue of calling CreateProcess())
A. Debugger (this is particularly true for VM and thread control operations)
B. Security/monitoring tools
C.Malware
OTOH, don’t forget that a “regular” Windows user process normally hosts
dozens of modules.
Therefore, it may well happen that some rogue DLL has hijacked an
unsuspecting process. In fact,
this is exactly the kind of experience that I recall from my “dark,
miserable and unfortunate days” of being a Windows developer/user (contrary
to Mr.Grig’s mantra about “never allowing users to run with root privilege
level” I was getting infected on a regular basis, despite routinely running
as a guest and logging in to admin account only when I absolutely had to).
This is exactly what I encountered every time I noticed that my machine was
sending out tons of traffic across the net…
Anton Bassov
—
NTDEV is sponsored by OSR
Visit the list online at: http:>
MONTHLY seminars on crash dump analysis, WDF, Windows internals and
software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at <
http://www.osronline.com/page.cfm?name=ListServer></http:></http:>
The question still remains what is the process doing opening another process in the first place? Bottom line, is there are few processes that need to open another process, and fewer that need all the privileges. At some point you are going to have to build a list of safe, questionable and bad processes. The challenge is always the questionable, and in the end the answer almost always involves querying the user.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of rohan kumbhar
Sent: Sunday, June 12, 2016 2:42 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Detecting Process code Injection using MS supported methods
@@ What is process X’s functionality if it needs to gain_any_ access to a process Y, in the first place @@
That’s simply difficult to identify the motive. I believe the malicious or suspicious activity is masked. Therefore for example, you could be presented a doc file. You open it and it drops an exe in the background, carries out its destructive activities while you read the doc in the frontend.
On Jun 13, 2016 12:04 AM, “rohan kumbhar” > wrote:
Hi,
There is no such supported method or callback in windows kernel to detect ntwritevirtualmemory, ntsuspendthread, ntsuspendprocess, ntsetcontextthread, ntresume*.
If you are tracing DLL injection then consider monitoring createthreadnotifyroutine alongside loadimage callback.
If you are tracing process hollowing on the fly in kernel, you will need to get creative by synchronizing user and kernel mode. It’s all about how well you dig into section objects. The resources are almost extinct.
On Jun 12, 2016 2:34 PM, > wrote:
> …it can be considered suspiciosu why some process would want the handle of another
> process with vm_write and all_access, of course there are legit reasons.
Good point…
I would suggest looking at this aspect in a more general way and to ask yourself “What is process X’s functionality if it needs to gain_any_ access to a process Y, in the first place”. To be honest, the only possible answers that get into my head are ( I assume X is not Y’s parent who gets a handle to Y simply by the virtue of calling CreateProcess())
A. Debugger (this is particularly true for VM and thread control operations)
B. Security/monitoring tools
C.Malware
OTOH, don’t forget that a “regular” Windows user process normally hosts dozens of modules.
Therefore, it may well happen that some rogue DLL has hijacked an unsuspecting process. In fact,
this is exactly the kind of experience that I recall from my “dark, miserable and unfortunate days” of being a Windows developer/user (contrary to Mr.Grig’s mantra about “never allowing users to run with root privilege level” I was getting infected on a regular basis, despite routinely running as a guest and logging in to admin account only when I absolutely had to). This is exactly what I encountered every time I noticed that my machine was sending out tons of traffic across the net…
Anton Bassov
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:>
@@ The question still remains what is the process doing opening another
process in the first place? @@
The process access mask does not really reveal the motive. We can group set
of probable activities that may be possible but cannot pinpoint any
activity.
@@ challenge is always questionable @@
Exactly.