Detect (and possibly block) WriteProcessMemory calls

Hey,

I know that we can capture OpenProcess calls that have write flag set, so
we can remove this flag and prevent WriteProcessMemory calls from Process A
to Process B.

But I wonder if we can capture WriteProcessMemory type of calls from
Process A to Process B from kernel. So I want to allow all OpenProcess
calls, but not certain WriteProcessMemory calls. Is it possible?

P.S. I don’t want to do any ring-3 hooks.

Thank you!

Did you try to use ObRegisterCallbacks API?
https://msdn.microsoft.com/en-us/library/windows/hardware/ff558692(v=vs.85).aspx

Another way to intercept WriteProcessMemory is a SSDT/VT hooks…
But it is really hard to implement and it is not recommended to use.

hooking is bad where ever you do it.

having said this, I am pretty sure WriteProcessmemory becomes a very
generic API in the kernel so the way people used to track this scenario
before. was in user land.

I havent explored the Hypervisor based approach, there are ways to do this
there.

On Fri, Dec 2, 2016 at 7:46 AM, AndroidT Tester
wrote:

> Hey,
>
> I know that we can capture OpenProcess calls that have write flag set, so
> we can remove this flag and prevent WriteProcessMemory calls from Process A
> to Process B.
>
> But I wonder if we can capture WriteProcessMemory type of calls from
> Process A to Process B from kernel. So I want to allow all OpenProcess
> calls, but not certain WriteProcessMemory calls. Is it possible?
>
> P.S. I don’t want to do any ring-3 hooks.
>
> Thank you!
> — 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

Thank you. I agree with your opinion on Hooking, that’s why we want to
avoid it as well.
Can you point me to some material to read about Hypervisor approach? Thank
you!

On Fri, Dec 2, 2016 at 2:50 PM, Ami Awbadhho wrote:

> hooking is bad where ever you do it.
>
> having said this, I am pretty sure WriteProcessmemory becomes a very
> generic API in the kernel so the way people used to track this scenario
> before. was in user land.
>
> I havent explored the Hypervisor based approach, there are ways to do this
> there.
>
>
>
>
>
>
> On Fri, Dec 2, 2016 at 7:46 AM, AndroidT Tester <
> xxxxx@gmail.com> wrote:
>
>> Hey,
>>
>> I know that we can capture OpenProcess calls that have write flag set, so
>> we can remove this flag and prevent WriteProcessMemory calls from Process A
>> to Process B.
>>
>> But I wonder if we can capture WriteProcessMemory type of calls from
>> Process A to Process B from kernel. So I want to allow all OpenProcess
>> calls, but not certain WriteProcessMemory calls. Is it possible?
>>
>> P.S. I don’t want to do any ring-3 hooks.
>>
>> Thank you!
>> — 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
>
>
> — 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

Have you tried to clear the PROCESS_VM_WRITE permission in the ACCESS_MASK within a kernel callback registred with ObRegisterCallbacks?

In this case, every OpenProcess call would succeed, but the returned handle would not allow write access to the target process’s address space.

The NtWriteVirtualMemory system service calls on ObReferenceObjectByHandle to obtain a referenced pointer to the target process with an ACCESS_MASK of (at least) PROCESS_VM_WRITE. If the PROCESS_VM_WRITE permission was cleared when the handle was opened, ObReferenceObjectByHandle should fail with STATUS_ACCESS_DENIED. So NtWriteVirtualMemory should fail with the same error status. WriteProcessMemory should then return ERROR_ACCESS_DENIED.

>WriteProcessMemory should then return ERROR_ACCESS_DENIED.

with recent os’s the error code is not always access_denied, just a word of
caution, not that it matters, unless you have a test case that specifically
checks for that error code.

On Fri, Dec 2, 2016 at 4:22 PM, wrote:

> Have you tried to clear the PROCESS_VM_WRITE permission in the ACCESS_MASK
> within a kernel callback registred with ObRegisterCallbacks?
>
> In this case, every OpenProcess call would succeed, but the returned
> handle would not allow write access to the target process’s address space.
>
> The NtWriteVirtualMemory system service calls on ObReferenceObjectByHandle
> to obtain a referenced pointer to the target process with an ACCESS_MASK of
> (at least) PROCESS_VM_WRITE. If the PROCESS_VM_WRITE permission was cleared
> when the handle was opened, ObReferenceObjectByHandle should fail with
> STATUS_ACCESS_DENIED. So NtWriteVirtualMemory should fail with the same
> error status. WriteProcessMemory should then return ERROR_ACCESS_DENIED.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> 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&gt;
></http:></http:>

>Can you point me to some material to read about Hypervisor approach? Thank
you!

https://github.com/tandasat/DdiMon

On Fri, Dec 2, 2016 at 1:16 PM, AndroidT Tester
wrote:

> Thank you. I agree with your opinion on Hooking, that’s why we want to
> avoid it as well.
> Can you point me to some material to read about Hypervisor approach? Thank
> you!
>
> On Fri, Dec 2, 2016 at 2:50 PM, Ami Awbadhho wrote:
>
>> hooking is bad where ever you do it.
>>
>> having said this, I am pretty sure WriteProcessmemory becomes a very
>> generic API in the kernel so the way people used to track this scenario
>> before. was in user land.
>>
>> I havent explored the Hypervisor based approach, there are ways to do
>> this there.
>>
>>
>>
>>
>>
>>
>> On Fri, Dec 2, 2016 at 7:46 AM, AndroidT Tester <
>> xxxxx@gmail.com> wrote:
>>
>>> Hey,
>>>
>>> I know that we can capture OpenProcess calls that have write flag set,
>>> so we can remove this flag and prevent WriteProcessMemory calls from
>>> Process A to Process B.
>>>
>>> But I wonder if we can capture WriteProcessMemory type of calls from
>>> Process A to Process B from kernel. So I want to allow all OpenProcess
>>> calls, but not certain WriteProcessMemory calls. Is it possible?
>>>
>>> P.S. I don’t want to do any ring-3 hooks.
>>>
>>> Thank you!
>>> — 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
>>
>>
>> — 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
>
>
> — 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
>

Hi,

“Hypervisor approach”
That’s last resort.
Use Dynamic binary instrumentation.
Libraries to use: Dynamorio, Intel Pin, Frida
google Frida github/opensource

Anyways if you land with Hypervisor:
Begin with: Simplevisor.
Google simplevisor

On Sat, Dec 3, 2016 at 7:06 AM, Ami Awbadhho wrote:

>
> >Can you point me to some material to read about Hypervisor approach?
> Thank you!
>
>
> https://github.com/tandasat/DdiMon
>
> On Fri, Dec 2, 2016 at 1:16 PM, AndroidT Tester <
> xxxxx@gmail.com> wrote:
>
>> Thank you. I agree with your opinion on Hooking, that’s why we want to
>> avoid it as well.
>> Can you point me to some material to read about Hypervisor approach?
>> Thank you!
>>
>> On Fri, Dec 2, 2016 at 2:50 PM, Ami Awbadhho wrote:
>>
>>> hooking is bad where ever you do it.
>>>
>>> having said this, I am pretty sure WriteProcessmemory becomes a very
>>> generic API in the kernel so the way people used to track this scenario
>>> before. was in user land.
>>>
>>> I havent explored the Hypervisor based approach, there are ways to do
>>> this there.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Dec 2, 2016 at 7:46 AM, AndroidT Tester <
>>> xxxxx@gmail.com> wrote:
>>>
>>>> Hey,
>>>>
>>>> I know that we can capture OpenProcess calls that have write flag set,
>>>> so we can remove this flag and prevent WriteProcessMemory calls from
>>>> Process A to Process B.
>>>>
>>>> But I wonder if we can capture WriteProcessMemory type of calls from
>>>> Process A to Process B from kernel. So I want to allow all OpenProcess
>>>> calls, but not certain WriteProcessMemory calls. Is it possible?
>>>>
>>>> P.S. I don’t want to do any ring-3 hooks.
>>>>
>>>> Thank you!
>>>> — 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
>>>
>>>
>>> — 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
>>
>>
>> — 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
>>
>
> — 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
>

>“https://github.com/tandasat/DdiMon

uses inline hooking.

Hooking in any aspect should be discouraged in the first place. Explore
alternatives.
If it is unavoidable, then make sure you test cycle is solid.

On Sun, Dec 4, 2016 at 7:09 PM, rohan kumbhar
wrote:

> Hi,
>
> >“Hypervisor approach”
> That’s last resort.
> Use Dynamic binary instrumentation.
> Libraries to use: Dynamorio, Intel Pin, Frida
> google Frida github/opensource
>
> Anyways if you land with Hypervisor:
> Begin with: Simplevisor.
> Google simplevisor
>
>
>
> On Sat, Dec 3, 2016 at 7:06 AM, Ami Awbadhho wrote:
>
>>
>> >Can you point me to some material to read about Hypervisor approach?
>> Thank you!
>>
>>
>> https://github.com/tandasat/DdiMon
>>
>> On Fri, Dec 2, 2016 at 1:16 PM, AndroidT Tester <
>> xxxxx@gmail.com> wrote:
>>
>>> Thank you. I agree with your opinion on Hooking, that’s why we want to
>>> avoid it as well.
>>> Can you point me to some material to read about Hypervisor approach?
>>> Thank you!
>>>
>>> On Fri, Dec 2, 2016 at 2:50 PM, Ami Awbadhho wrote:
>>>
>>>> hooking is bad where ever you do it.
>>>>
>>>> having said this, I am pretty sure WriteProcessmemory becomes a very
>>>> generic API in the kernel so the way people used to track this scenario
>>>> before. was in user land.
>>>>
>>>> I havent explored the Hypervisor based approach, there are ways to do
>>>> this there.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Dec 2, 2016 at 7:46 AM, AndroidT Tester <
>>>> xxxxx@gmail.com> wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> I know that we can capture OpenProcess calls that have write flag set,
>>>>> so we can remove this flag and prevent WriteProcessMemory calls from
>>>>> Process A to Process B.
>>>>>
>>>>> But I wonder if we can capture WriteProcessMemory type of calls from
>>>>> Process A to Process B from kernel. So I want to allow all OpenProcess
>>>>> calls, but not certain WriteProcessMemory calls. Is it possible?
>>>>>
>>>>> P.S. I don’t want to do any ring-3 hooks.
>>>>>
>>>>> Thank you!
>>>>> — 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
>>>>
>>>>
>>>> — 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
>>>
>>>
>>> — 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
>>>
>>
>> — 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
>>
>
>

We know about the ObRegisterCallbacks as I mentioned in my original
question. We want to allow Write access, just to detect WriteProcessMemory
calls from process A to B, even we want to allow A to A writes. But thank
you, will check hypervisor approach, but if anyone else have other ideas I
would really appreciate any pointer. Thank you

On Sun, Dec 4, 2016 at 8:43 AM, rohan kumbhar
wrote:

> >“https://github.com/tandasat/DdiMon
>
> uses inline hooking.
>
> Hooking in any aspect should be discouraged in the first place. Explore
> alternatives.
> If it is unavoidable, then make sure you test cycle is solid.
>
> On Sun, Dec 4, 2016 at 7:09 PM, rohan kumbhar
> wrote:
>
>> Hi,
>>
>> >“Hypervisor approach”
>> That’s last resort.
>> Use Dynamic binary instrumentation.
>> Libraries to use: Dynamorio, Intel Pin, Frida
>> google Frida github/opensource
>>
>> Anyways if you land with Hypervisor:
>> Begin with: Simplevisor.
>> Google simplevisor
>>
>>
>>
>> On Sat, Dec 3, 2016 at 7:06 AM, Ami Awbadhho wrote:
>>
>>>
>>> >Can you point me to some material to read about Hypervisor approach?
>>> Thank you!
>>>
>>>
>>> https://github.com/tandasat/DdiMon
>>>
>>> On Fri, Dec 2, 2016 at 1:16 PM, AndroidT Tester <
>>> xxxxx@gmail.com> wrote:
>>>
>>>> Thank you. I agree with your opinion on Hooking, that’s why we want to
>>>> avoid it as well.
>>>> Can you point me to some material to read about Hypervisor approach?
>>>> Thank you!
>>>>
>>>> On Fri, Dec 2, 2016 at 2:50 PM, Ami Awbadhho
>>>> wrote:
>>>>
>>>>> hooking is bad where ever you do it.
>>>>>
>>>>> having said this, I am pretty sure WriteProcessmemory becomes a very
>>>>> generic API in the kernel so the way people used to track this scenario
>>>>> before. was in user land.
>>>>>
>>>>> I havent explored the Hypervisor based approach, there are ways to do
>>>>> this there.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Dec 2, 2016 at 7:46 AM, AndroidT Tester <
>>>>> xxxxx@gmail.com> wrote:
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> I know that we can capture OpenProcess calls that have write flag
>>>>>> set, so we can remove this flag and prevent WriteProcessMemory calls from
>>>>>> Process A to Process B.
>>>>>>
>>>>>> But I wonder if we can capture WriteProcessMemory type of calls from
>>>>>> Process A to Process B from kernel. So I want to allow all OpenProcess
>>>>>> calls, but not certain WriteProcessMemory calls. Is it possible?
>>>>>>
>>>>>> P.S. I don’t want to do any ring-3 hooks.
>>>>>>
>>>>>> Thank you!
>>>>>> — 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
>>>>>
>>>>>
>>>>> — 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
>>>>
>>>>
>>>> — 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
>>>>
>>>
>>> — 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
>>>
>>
>>
> — 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
>