Re: NTFS file access auditing

[Dexter Caldwell <Dexter.Caldwell () FURMAN EDU>]

If you're willing to put in some effort, you might be able to download
LogParser from Microsoft and get some use from it.  It's a command-line
tool (essentially uses SQL queries) but can generate graphical report info
too.  Also there are books written on it (see Amazon.com), and you can
also find a few GUIs around the net that help simply what you're trying to
do.  Also, Log Parser can parse a lot more than just Event Logs too- it
can parse things like IIS, Snort IDS, Exchange, etc.

Of course, the obvious solution if you have a SIEM is to see what that
will do with your logs first, but I'm assuming if that was an option you
wouldn't be asking.

Thanks,

Dexter Caldwell
Furman University
3300 Poinsett Hwy

The EDUCAUSE Security Constituent Group Listserv
<SECURITY () LISTSERV EDUCAUSE EDU> writes:
> Thanks for the response Mike.  I'll have to do some more testing, but the
> tricky part was telling the difference between opening the directory with
> Windows Explorer versus a drag-and-drop copy of the file(s) with Windows
> Explorer.  Double-clicking the file should trigger an execution audit log
> (assuming that has been enabled), but my initial look didn't reveal an
> easy
> differentiation between opening the folder and copying the file.  I'll
> continue to take a deeper look.  
>
> Brad Judy
>
> Emory University
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Mike Lococo
> Sent: Wednesday, April 28, 2010 3:29 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] NTFS file access auditing
>
> On 04/28/2010 01:56 PM, Brad Judy wrote:
> > If I instead open the directory in Windows explorer (at least under
> > Windows 7), it will trigger a read audit log for all of the files in
> > the directory. Following both of these actions in process monitor
> > (great tool - learn it) shows that they are indeed very different and
> > the GUI browsing does request a handle for each of the files in the
> > directory and opens them. Presumably this is done to request detailed
> > file information for GUI display.
> >
> > Unfortunately, this means the audit logs are deceiving, showing no
> > difference between browsing into a folder and actually opening the
> > files. Has anyone else tackled this issue? Did you do so natively, or
> > using a third-party audit solution?
>
> While I certainly don't have a turnkey solution for pretty 
> human-readable reports, I can say that the explorer accesses are 
> distinguishable from other types if your tool/analysis is sufficiently 
> intelligent.
>
> My need to parse access audit logs from windows systems is primarily 
> forensic and quite infrequent, so my process is manual and requires more 
> than passing familiarily with interpreting event logs.  Psloglist.exe 
> from the sysinternals pstools is a good way to get extracts of windows 
> event logs, and shows that the following artifacts are observable:
>
>   1) The process name and number of the process whose activity
>      generated the event is recorded.  One very simple indicator that
>      browsing activity is happening is that explorer.exe is the trigger
>      process.  Unfortunately, Event Viewer doesn't seem able to display
>      this info as a column or search on it, making it quite difficult
>      to interact with using that tool.
>
>   2) The type of access is recorded (also not viewable as a
>      column/search in EV), and you'll typically find that explorer.exe
>      accesses are often grabbing attributes whereas accesses from
>      another program (like notepad) will show reads and writes and a
>      longer list of stuff.  This is less trivial to parse, but I
>      believe they tell a fairly rich story about the kind of access
>      that occurred.
>
> So I'm sure this isn't the answer you wanted in terms of a 
> recommendation for a rich and user-friendly reporting tool, but it's at 
> least a confirmation that there is some useful data in there if you can 
> find a vendor who does something useful with it.
>
> Also, third-party file-service tools may have less obtuse logging 
> options.  We use Xythos, and although I haven't had occasion to review 
> its audit logs much, I believe that they are fairly rich.
>
> Please report back if you find a good answer, as I'm interested as well.
>
> Cheers,
> Mike Lococo