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