Differentiate FILE_OPENED events - determine when user had opened a file on Notepad?

Information from IoStatusBlock at Post Create is able to show when files are being opened giving the FILE_OPENED value. When a file is being clicked on in Windows File Explorer, opened up on Notepad, closed on Notepad, etc they all return the FILE_OPENED value. If it is the case of a directory, typing “dir” on the command line will also cause a FILE_OPENED.

What I am trying to do is to differentiate each of the above events in more detail. Eg when a user simply clicks on the file on Windows File Explorer, I’d like to know that this is the case, and it is not because he/she opened the file on Notepad. A more critical scenario is to audit when the user had opened a file, and not happened to just clicked on the file in Explorer.

I had tried placing debug messages in the Pre and Post Operations of IRP_MJ_CREATE, IRP_MJ_WRITE, IRP_MJ_CLOSE, IRP_MJ_CLEANUP, IRP_MJ_READ, IRP_MJ_SET_INFORMATION and IRP_MJ_QUERY_INFORMATION to detect any patterns of callbacks that can tell the difference of the events I stated earlier. However, I was not able to spot anything telling.

I am perceiving that this is because the kernel level is only able to detect when files are being opened, and not how. Should Notepad open or close a text file, it does not make any difference to the kernel. If this is correct, can I still achieve what I am trying to? Would appreciate any direction that anyone can point me towards.

Thanks.

> I am perceiving that this is because the kernel level is only able to

detect when files are being opened, and not how.

Correct, but there are some hints in there too.

• You can get the ACCESS_MODE of the open (was it open for write, or just
  for read)
• You can (usually) get the process which is active as the create is
  happening
• You can always get the (security) Principal which is opening the file (or
  on who’s behalf the file is being opened)

But there is an important thing you have to bear in mind. If a file has
been opened for a purpose (read, or write or whatever) then there is no safe
assumption except that the file will be used for that purpose. It may have
been explorer that opened the file, but there is absolutely nothing to stop
the HANDLE being passed to other (e.g.child) processes to do whatever they
want with. When you are writing security code, or you are in the kernel
(and by virtue of asking in this group you are doing both) you cannot rely
on “usually”…

What are you trying to achieve?

/Rod

Thanks Rod.

I’d like to audit as accurately as possible every file and directory events
that a user does on the computer. I have so far managed to capture all the
FILE_OPENED, FILE_DELETED, FILE_CREATED, FILE_MODIFIED events. As observed,
even if the user simply clicks on a file on File Explorer, the
IRP_MJ_CREATE flags up that FILE_OPENED has occurred - the same if Notepad
has opened the same file, or closed the same file. What I get is a list of
FILE_OPENED on the same file but on different time stamps. Hence, I
currently do not have a way to determine what the actual event was.

More critically, if a user has accessed a file of interest to the
organization, I’d want to clearly point out that the user had opened it
using Notepad (or Word or whatever), and that it was not a case when the
user just so happened to run his cursor over the sensitive file, or some
other service had triggered the FILE_OPENED without the user’s knowledge
(eg antivirus).

I am thinking about getting the application name that opened the file (or
Process ID at the kernel level and then I’ll have user mode to discover the
Image pertaining to the Process ID) would be good evidence. But…

> You can (usually) get the process which is active as the create is
happening
> When you are writing security code, or you are in the kernel (and by
virtue of asking in this group you are doing both) you cannot rely on
“usually”…
Agreed. Therefore I’m thinking of what you wrote next…

> You can always get the (security) Principal which is opening the file
(or on who’s behalf the file is being opened)
This reads to me like a plausible approach if I am understanding it
correctly. By “Principal”, what do you mean?

On Mon, Sep 10, 2018 at 8:36 PM Rod Widdowson <
xxxxx@lists.osr.com> wrote:

> > I am perceiving that this is because the kernel level is only able to
> > detect when files are being opened, and not how.
>
> Correct, but there are some hints in there too.
>
> - You can get the ACCESS_MODE of the open (was it open for write, or just
> for read)
> - You can (usually) get the process which is active as the create is
> happening
> - You can always get the (security) Principal which is opening the file
> (or
> on who’s behalf the file is being opened)
>
> But there is an important thing you have to bear in mind. If a file has
> been opened for a purpose (read, or write or whatever) then there is no
> safe
> assumption except that the file will be used for that purpose. It may
> have
> been explorer that opened the file, but there is absolutely nothing to
> stop
> the HANDLE being passed to other (e.g.child) processes to do whatever they
> want with. When you are writing security code, or you are in the kernel
> (and by virtue of asking in this group you are doing both) you cannot rely
> on “usually”…
>
> What are you trying to achieve?
>
> /Rod
>
>
> —
> NTFSD is sponsored 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://www.osronline.com/page.cfm?name=ListServer&gt;
>

–
Regards,
CA</http:>

First, I will suggest that if you have to ask what is meant by ?security principal?, you are woefully unequipped to unequipped to build a security auditing product like this.

Second, let me suggest that you consider user mode GDI hooks. This will only let you audit the activities of applications that you ?understand?, and they can be variously circumvented, but will provide a much better correlation with your requirements.

In a general sense, you cannot ascribe any particular ?action? from a user to a sequence of IOCTLs etc. By the time you can observer or filter anything, there is no direct association. So you can code something generic, that will always work, but doesn?t log anything other than opens and closes ? or something that works much better, but relies of application specific behaviours ? something vastly easier to implement in UM

Sent from Mailhttps: for Windows 10

________________________________
From: xxxxx@lists.osr.com on behalf of CA Tan
Sent: Monday, September 10, 2018 1:11:01 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Differentiate FILE_OPENED events - determine when user had opened a file on Notepad?

Thanks Rod.

I’d like to audit as accurately as possible every file and directory events that a user does on the computer. I have so far managed to capture all the FILE_OPENED, FILE_DELETED, FILE_CREATED, FILE_MODIFIED events. As observed, even if the user simply clicks on a file on File Explorer, the IRP_MJ_CREATE flags up that FILE_OPENED has occurred - the same if Notepad has opened the same file, or closed the same file. What I get is a list of FILE_OPENED on the same file but on different time stamps. Hence, I currently do not have a way to determine what the actual event was.

More critically, if a user has accessed a file of interest to the organization, I’d want to clearly point out that the user had opened it using Notepad (or Word or whatever), and that it was not a case when the user just so happened to run his cursor over the sensitive file, or some other service had triggered the FILE_OPENED without the user’s knowledge (eg antivirus).

I am thinking about getting the application name that opened the file (or Process ID at the kernel level and then I’ll have user mode to discover the Image pertaining to the Process ID) would be good evidence. But…
>> You can (usually) get the process which is active as the create is happening
>> When you are writing security code, or you are in the kernel (and by virtue of asking in this group you are doing both) you cannot rely on “usually”…
Agreed. Therefore I’m thinking of what you wrote next…

>> You can always get the (security) Principal which is opening the file (or on who’s behalf the file is being opened)
This reads to me like a plausible approach if I am understanding it correctly. By “Principal”, what do you mean?

On Mon, Sep 10, 2018 at 8:36 PM Rod Widdowson > > wrote:
> I am perceiving that this is because the kernel level is only able to
> detect when files are being opened, and not how.

Correct, but there are some hints in there too.

- You can get the ACCESS_MODE of the open (was it open for write, or just
for read)
- You can (usually) get the process which is active as the create is
happening
- You can always get the (security) Principal which is opening the file (or
on who’s behalf the file is being opened)

But there is an important thing you have to bear in mind. If a file has
been opened for a purpose (read, or write or whatever) then there is no safe
assumption except that the file will be used for that purpose. It may have
been explorer that opened the file, but there is absolutely nothing to stop
the HANDLE being passed to other (e.g.child) processes to do whatever they
want with. When you are writing security code, or you are in the kernel
(and by virtue of asking in this group you are doing both) you cannot rely
on “usually”…

What are you trying to achieve?

/Rod

—
NTFSD is sponsored 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:

–
Regards,
CA
— NTFSD is sponsored by OSR 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:></https:>