A driver that listens to traffic

Basically I want a driver that hook the networking functions in the kernel so I can monitor which processes called connect,send, bind etc. At first,I was expecting the winsock functions in windows would be calling a system call in the SSDT table but it seems the table has no functions that would do networking? So how to make a driver that listens to these function calls ?

xxxxx@gmail.com wrote:

Basically I want a driver that hook the networking functions in the kernel so I can monitor which processes called connect,send, bind etc. At first,I was expecting the winsock functions in windows would be calling a system call in the SSDT table but it seems the table has no functions that would do networking?

Of course not. Networking is not a fundamental kernel concept. A
network is just another driver providing I/O services. You talk to it
through ReadFile, WriteFile, and DeviceIoControl, just like every other
I/O service.

So how to make a driver that listens to these function calls ?

Certainly not by SSDT hooking. You should probably look at the Windows
Filtering Platform, which was designed to allow that kind of operation
without hackery.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

You need the Windows Filtering Platform, I just did a driver like this for a
client. No, you never want to use SSDT hooking.

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@gmail.com
Sent: Friday, July 29, 2016 5:23 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] A driver that listens to traffic

Basically I want a driver that hook the networking functions in the kernel
so I can monitor which processes called connect,send, bind etc. At first,I
was expecting the winsock functions in windows would be calling a system
call in the SSDT table but it seems the table has no functions that would do
networking? So how to make a driver that listens to these function calls ?


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:>

Forget SSDT hooking. Forever. With the Device Guard in Srv2016, it is now totally impossible in a production environment. And yes, Win10 can also be deployed using the same policies which are default in Srv2016.

What you need is a Windows Filtering Platform plugin to tcpip.sys, which is well-documented.

You do not need to track the socket APIs exactly. You only need to know what socket belongs to what process and what data is going via it. WFP allows this.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Basically I want a driver that hook the networking functions in the kernel so I can monitor which processes called connect,send, bind etc. At first,I was expecting the winsock functions in windows would be calling a system call in the SSDT table but it seems the table has no functions that would do networking? So how to make a driver that listens to these function calls ?
>

@Don Burn

Can I retrieve the process of every packet ? Are there any packets that we cannot associate to a process ?

I was able to get the PID and Port for all the calls my client was concerned
about namely BIND, UNBIND and CONNECT. BIND will also provide the path to
the executable.

Be aware that the recommend sample is the “Windows Filtering Platform
Sample” which is huge. In my case I was able to bring it down to a little
over 1100 lines of code to monitor and log those calls including comments.

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@gmail.com
Sent: Saturday, July 30, 2016 3:06 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] A driver that listens to traffic

@Don Burn

Can I retrieve the process of every packet ? Are there any packets that we
cannot associate to a process ?


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

Can a process make the OS sends a packet on its behalf? Or can a malware do that to hide it’s identity?

Thanks.

For any normal situation the filter will catch all the packets, including
ones from the OS. If you can insert code into the OS there is never a
guarantee that someone can’t figure out a way to bypass any protection
mechanism you have. This is why if you look back in the archives most of us
emphasize that if the kernel is infected there is no way to fix things.

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@gmail.com
Sent: Sunday, July 31, 2016 7:16 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] A driver that listens to traffic

@ Don

Can a process make the OS sends a packet on its behalf? Or can a malware do
that to hide it’s identity?

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:>

I compiled the driver and used net start inspect to start the service. The code seems to complex for me but I found some functions in inspect.c

TLInspectALERecvAcceptClassify

TLInspectALERecvAcceptNotify

I put a dbgPrint statement in them but they don’s seem to be the functions that are called when recv is called because they are only called once or twice! Also there is something called “ale” which I don’t seem to understand!

ALE layers are described here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb613460(v=vs.85).aspx

ALE is described here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363971(v=vs.85).aspx

I was able to capture all the packets. but still have no idea how to get
the process associated with each packer?

On Sun, Jul 31, 2016 at 4:38 PM, Don Burn wrote:

> For any normal situation the filter will catch all the packets, including
> ones from the OS. If you can insert code into the OS there is never a
> guarantee that someone can’t figure out a way to bypass any protection
> mechanism you have. This is why if you look back in the archives most of
> us
> emphasize that if the kernel is infected there is no way to fix things.
>
>
> 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@gmail.com
> Sent: Sunday, July 31, 2016 7:16 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] A driver that listens to traffic
>
> @ Don
>
> Can a process make the OS sends a packet on its behalf? Or can a malware do
> that to hide it’s identity?
>
> 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:> 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:></http:></http:></http:>

Take a look at https://msdn.microsoft.com/en-us/library/windows/hardware/ff559179(v=vs.85).aspx If you test for TRUE
“FWPS_IS_METADATA_FIELD_PRESENT( MetaValues, FWPS_METADATA_FIELD_PROCESS_ID )” you can then retrieve the
PID from MetaValues->processId;

This is in the WFP sample, but as I warned you at the beginning it is a huge sample. You are going to have to study the MSDN
Documentation to know what you can get where to get data, start you doc search at https://msdn.microsoft.com/en-us/library/windows/hardware/ff546100(v=vs.85).aspx

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 zaid ALYAFEY
Sent: Friday, August 05, 2016 3:02 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] A driver that listens to traffic

I was able to capture all the packets. but still have no idea how to get the process associated with each packer?

On Sun, Jul 31, 2016 at 4:38 PM, Don Burn > wrote:

For any normal situation the filter will catch all the packets, including
ones from the OS. If you can insert code into the OS there is never a
guarantee that someone can’t figure out a way to bypass any protection
mechanism you have. This is why if you look back in the archives most of us
emphasize that if the kernel is infected there is no way to fix things.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com mailto:xxxxx
[mailto:xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of xxxxx@gmail.com mailto:xxxxx
Sent: Sunday, July 31, 2016 7:16 AM
To: Windows System Software Devs Interest List >
Subject: RE:[ntdev] A driver that listens to traffic

@ Don

Can a process make the OS sends a packet on its behalf? Or can a malware do
that to hide it’s identity?

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: >

— 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:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

One more question,

What I understood that we can get the process id at the layers for connect,
accept and bind (handshake layers). But what about the packets generated by
(send, recv) function calls ? Also from msdn I have the following "only the
first TCP *send()*
https:
and
the first TCP recv()
https:
over
raw sockets will be filtered. " what does that mean ?

On Fri, Aug 5, 2016 at 10:20 PM, Don Burn wrote:

> Take a look at https://msdn.microsoft.com/en-us/library/windows/hardware/
> ff559179(v=vs.85).aspx If you test for TRUE
> “FWPS_IS_METADATA_FIELD_PRESENT( MetaValues,
> FWPS_METADATA_FIELD_PROCESS_ID )” you can then retrieve the
> PID from MetaValues->processId;
>
> This is in the WFP sample, but as I warned you at the beginning it is a
> huge sample. You are going to have to study the MSDN
> Documentation to know what you can get where to get data, start you doc
> search at https://msdn.microsoft.com/en-us/library/windows/hardware/
> ff546100(v=vs.85).aspx
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-613882-122747@
> lists.osr.com] On Behalf Of zaid ALYAFEY
> Sent: Friday, August 05, 2016 3:02 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] A driver that listens to traffic
>
> I was able to capture all the packets. but still have no idea how to get
> the process associated with each packer?
>
> On Sun, Jul 31, 2016 at 4:38 PM, Don Burn > xxxxx@windrvr.com> > wrote:
>
>
> For any normal situation the filter will catch all the packets,
> including
> ones from the OS. If you can insert code into the OS there is
> never a
> guarantee that someone can’t figure out a way to bypass any
> protection
> mechanism you have. This is why if you look back in the archives
> most of us
> emphasize that if the kernel is infected there is no way to fix
> things.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com mailto:> xxxxx@lists.osr.com>
> [mailto:xxxxx@lists.osr.com mailto:> xxxxx@lists.osr.com>] On Behalf Of xxxxx@gmail.com
> mailto:xxxxx
> Sent: Sunday, July 31, 2016 7:16 AM
> To: Windows System Software Devs Interest List <
> xxxxx@lists.osr.com mailto:xxxxx >
> Subject: RE:[ntdev] A driver that listens to traffic
>
>
> @ Don
>
> Can a process make the OS sends a packet on its behalf? Or can a
> malware do
> that to hide it’s identity?
>
> Thanks.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at:
> http:> http://www.osronline.com/showlists.cfm?list=ntdev&gt; >
>
> 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://www.osronline.com/page.cfm?name=ListServer&gt; >
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev 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 <
> http://www.osronline.com/page.cfm?name=ListServer&gt; >
>
>
>
> — 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: 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:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></mailto:></mailto:></https:></https:>

> only the first TCP *send()* https: and the first TCP recv() https: over raw sockets will be filtered. " what does that mean ?

This is only relavent at the ALE layers: https://msdn.microsoft.com/en-us/library/windows/desktop/bb613460(v=vs.85).aspx

If you want to associate every packet with a process you’ll need to look at the Transport / IP layers. It looks like the processid is not immediately available at these layers. (https://msdn.microsoft.com/en-us/library/windows/hardware/ff559179(v=vs.85).aspx)

Looks like you’ll need to maintain your own state tables for this or store it the processid in the flow context and retrieve it at these layers.

J</https:></https:>

Since I know the process id of each packet in ale connect , can’t I
associate every send or receive packet with the corresponding connection?
On 15 Aug 2016 17:37, wrote:

> > only the first TCP send() https:> en-us/library/windows/desktop/ms740149(v=vs.85).aspx> and the first TCP
> recv() https:> ms740121(v=vs.85).aspx> over raw sockets will be filtered. " what does
> that mean ?
>
> This is only relavent at the ALE layers: https://msdn.microsoft.com/en-
> us/library/windows/desktop/bb613460(v=vs.85).aspx
>
> If you want to associate every packet with a process you’ll need to look
> at the Transport / IP layers. It looks like the processid is not
> immediately available at these layers. (https://msdn.microsoft.com/
> en-us/library/windows/hardware/ff559179(v=vs.85).aspx)
>
> Looks like you’ll need to maintain your own state tables for this or store
> it the processid in the flow context and retrieve it at these layers.
>
> J
>
> —
> 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:></https:></https:>

Zaid alyafeai wrote:

> Looks like you’ll need to maintain your own state tables for
> this or store it the processid in the flow context and retrieve
> it at these layers.

Since I know the process id of each packet in ale connect , can’t I
associate every send or receive packet with the corresponding
connection?

Uh, isn’t that what you were *just* told?

Hi

As far as I know,ale connect and ale recv accept flow context cannot be got in transport layers.

We need to maintain our own context for example search key will be 5 tuple.


From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Thursday, August 18, 2016 8:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] A driver that listens to traffic

Zaid alyafeai wrote:

>> Looks like you’ll need to maintain your own state tables for
>> this or store it the processid in the flow context and retrieve
>> it at these layers.
>
> Since I know the process id of each packet in ale connect , can’t I
> associate every send or receive packet with the corresponding
> connection?

Uh, isn’t that what you were just told?


NTDEV is sponsored by OSR

Visit the list online at: http:
OSR Online NTDEV Listhttp:
www.osronline.com
OSR Online is the homepage for Windows driver writers. The NTDEV, NTFSD, and NTTALK lists are world-wide peer support forums administered by OSR.

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:>

As far as I know,ale connect and ale recv accept flow context cannot be got in
transport layers.

We need to maintain our own context for example search key will be 5 tuple.

How do I know that two packets in the transport layer belong to the same
tcp connection ?
On 18 Aug 2016 13:01, wrote:

> As far as I know,ale connect and ale recv accept flow context cannot be
> got in
> transport layers.
>
> We need to maintain our own context for example search key will be 5
> tuple.
>
> —
> 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:>

At least for most cases check out FWPS_METADATA_FIELD_TRANSPORT_ENDPOINT_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 zaid ALYAFEY
Sent: Friday, August 19, 2016 5:22 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] A driver that listens to traffic

How do I know that two packets in the transport layer belong to the same tcp connection ?

On 18 Aug 2016 13:01, > wrote:

As far as I know,ale connect and ale recv accept flow context cannot be got in
transport layers.

We need to maintain our own context for example search key will be 5 tuple.


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:>