Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

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

CA_TanCA_Tan Posts: 10
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.

Comments

  • > 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
  • CA_TanCA_Tan Posts: 10
    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
    >
    > To unsubscribe, visit the List Server section of OSR Online at <
    > http://www.osronline.com/page.cfm?name=ListServer>;
    >


    --
    Regards,
    CA
  • M_M-2M_M-2 Posts: 833
    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 Mail 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

    To unsubscribe, visit the List Server section of OSR Online at


    --
    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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!