How can I find out which process and user is modifying a file?


When troubleshooting a problem, you may discover that a file is being modified that shouldn't, and you figure out would be nice if there were some way of finding out which process is modifying the file (so you can get it to stop).

Enter the security auditing system.

Every securable object has an associated system access control list (SACL) which controls what audit events are raised when a request is made to access the object. You can say, for example, "Log an event in the security event log if somebody tries to open this file for writing but is denied access," or "Log an event in the security event log if somebody successfully creates a new file in this directory."

Here's how it works. Let's say that you want to access successful requests from any user to write to a particular file.

View the Properties of the file, go to the Security tab, and click Advanced, then go to the Auditing tab and elevate to administrator if necessary.

Next, click Add. What happens next depends on what version of Windows you're using, since the interface varies slightly (but the basic idea remains the same). When asked for the security principal, set the Location to the local computer and use the object name Everyone.

Older vesions of Windows will give you a grid of options. Look for the row corresponding to the operation you want to audit and check the box under Successful if you want to audit successful accesses or the box under Failed to audit failed accesses. (Or check both to audit both successful and failed accesses.) Repeat for each access you want to audit. In our case, we would check the Create files / write data and Create folders / append data boxes under the Successful column.

Newer versions of Windows break the grid up into two questions. The first is whether you want to audit Success, Fail, or All access. In our case, we want to audit Success. The next question is what type of access you want to audit, and in our case we would check Write. (Or for finer control, click Show advanced permissions and check Create files / write data and Create folders / append data.)

OK your way out of all the dialog boxes to save the changes.

All right, let's take this thing out for a spin. Open the file in Notepad, make some change, and then Save them. Now open the Event Viewer and go to the Security event log.

And... no log entry.

That's because I forgot a step: You have to enable object access auditing.

Open the Control Panel and look in the Administrative Tools folder. From there, you can run the Local Security Policy snap-in. If you are a command line nerd, you can run secpol.msc.

Under Local Policies, Audit Policy set the Audit object access policy to enable global auditing of successful or failed accesses, depending on what you need.

Okay, let's try it again. Modify the file and save it. Now go back to the security event viewer and you'll see audit success events in your log. Again, depending on what version of Windows you're using, the successful audit event will appear differently. For example, older versions of Windows might show

Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 567
Date: ...
Time: ...
User: ...
Computer: ...
Description:
Object Access Attempt:
Object Server: Security
Handle ID: 208
Object Type: File
Process ID: 1964
Image File Name: C:\WINDOWS\system32\notepad.exe
Access Mask: WriteData (or AddFile)
AppendData (or AddSubdirectory or CreatePipeInstance)

whereas newer versions might show

Keywords: Audit Success
Date and Time: ...
Source: Microsoft Windows security auditing
Event ID: 4663
Task Category: File System
An attempt was made to access an object.
Subject:
Security ID: computer\user
Account Name: user
Account Domain: computer
Logon ID: 0x27ADB
Object:
Object Server: Security
Object Type Name: File
Object Name: C:\test.txt
Handle ID: 0x15c
Resource Attributes: S:AI
Process Information:
Process ID: 0xdb0
Process Name: C:\Windows\System32\notepad.exe
Access Request Information:
Accesses: WriteData (or AddFile)
AppendData (or AddSubdirectory or CreatePipeInstance)
Access Mask: 0x6

Either way, you can see which process obtained write access to the file, running as what user, at what time.

Newer versions of Windows include a bit more information in the event log entry to make it easier to find the access request you're looking for as well as chase the access further. (For example, from the Logon ID, you can figure out which logon session modified the file.)

This feature has been around since the beginning of Windows NT, but it seems that very few people know about it. Whenver I point it out to people, they say, "Hey, that's cool. How long has that feature been there?"

Now you too can look smart.

Comments (26)
  1. John says:

    >Whenever I point it out to people, they say, "Hey, that's cool. Process Monitor is better."

    I guess auditing would be more useful in a scenario where it's not feasible to leave Process Monitor running for hours at a time.

  2. kinokijuf says:

    The difference is that Procmon is a debugging tool, not a security tool.

  3. kog999 says:

    One problem with auditing is the the security event log fills up so fast. particully with windows firewall releasted events. by default on most systems i've seen it will roll over within a day or 2 and if your on a file server or something like that it could roll over in less then an hour. You could increase the maximum log size but you have a ton of logs to go though 99% of which you dont care about, although filtering will help. It might be helpful in a situation where you know a process is going to access the file in the next 10 mintues and you want to know what the process it, but in a situation where the file might get opened in the next week its a real pain. And if you want to do any real auditing where you can review who accessed what over say the last 6 months your going to need a third party product.

  4. Rick C says:

    This might actually be useful for me–nice coincidence.  One of our customers is trying to figure out how a bogus file is being created (something's creating c:program, which we all know causes all kinds of heartache.)

    Is the auditing tool smart enough to keep looking for file creation if the file is deleted?  In other words if I create c:program and put an audit on it, and then delete it so it doesn't cause trouble, will it still fire another event if the file is subsequently recreated?

    I will try it out to see if it works, but I want to leave the comment here anyway both to get an actual answer and on the off chance someone else has the same problem.

  5. Mark says:

    Rick C: no, the ACL is lost when the directory is deleted (for obvious reasons). You'll need to audit Create file/folder for C:.

  6. Rick C says:

    Sadly, I guess the policy goes with the file, because it looks like when you delete it, you don't get an audit record when you re-create the file.  Maybe an audit on C: would work, but I'm not going to try that out right now.

  7. Kookiz says:

    @Rick C  

    I suppose you can audit the "Create File" event directly at the folder level.

  8. Rick C says:

    Mark,

    Yup, looks like you're right.  As I was typing up the first comment I thought that might be the case, but I figured it was still worth checking.

  9. A. Skrobov says:

    Didn't Raymond already write about this half a year ago?

    blogs.msdn.com/…/10412074.aspx

  10. kinokijuf says:

    @A. Skrobov Of course he did. The world ended in December and what you are seeing now is just reruns. ( blogs.msdn.com/…/10168424.aspx )

  11. Olivier says:

    Is the security audit system used under the hood by GFlags to track "silent process exits"?

    blogs.msdn.com/…/windows-debugging-tricks-who-killed-my-process.aspx

  12. Andreas Nilsson says:

    Another way: Is it possible to trace file operations / changes by the Running Object Table?

    By the way; who is hosting the ROT-object (Explorer.exe?)?

  13. John says:

    >The difference is that Procmon is a debugging tool, not a security tool.

    The problem as presented here is not one of security but of troubleshooting.  This is one of those situations where Windows has some built in functionality that, while not specifically designed for a given scenario, can fit the bill if needed.

  14. alegr1 says:

    @Andreas:

    Running Object Table tracks COM documents, not files.

  15. Nick says:

    Process Monitor actually can work pretty well left running for long periods of time if you know something of what you're looking for beforehand.  The trick is to setup a fairly tight filter and then check the "Drop Filtered Events" option in the Filter menu.  That way you're not filling up memory with stuff you don't care about.

    @Rick

    For your case, you might try creating a Process Monitor filter for "Path Name [is] C:Program".  Enable the drop filtered events option and just let it run.

    Knowing what you can do with the default tools provided is absolutely worthwhile. But so is using the right tool for the job :)

  16. JamesNT says:

    I am also utterly dismayed at the number of developers and, especially, IT Pros out there who rarely, if ever, use the event viewer.  

    It's saddening.

    JamesNT

  17. alegr1 says:

    @JamesNT:

    The event viewer is one of the worst written pieces of Windows software. Extremely slow to start and open the logs, with extremely slow unstable sort (stable sort keeps order of items with equal key). It's become much worse in Vista+.

  18. Engywuck says:

    I knew about SACL (hey, they were asked about in MCSE2003 :-)), but I was told "sure, it exists, but enabling auditing makes the server slow", so I never enabled it on my fileservers.

    Is this (still) true?

  19. Gabe says:

    Engywuck: It's not enabling of auditing that slows down the server, but the auditing itself. When NT first came out in 1993, it was easy to slow down your 25MHz 386 server. Back then just processing an SACL was a measurable amount of work. Twenty years later, you'd probably never notice if you enable auditing on every file.

    The key is to not audit access to every file, just the ones your really care about. For example, if you audit read success on every file in the Windows directory, creating any process will spend time writing log entries.

  20. Mc says:

    Wow I didn't know about this.   That could come in very handy.   I already use Sysinternals' ProcMon,  but with this you can easily target a particular file or directory.

    Thank you!

  21. dave says:

    >The event viewer is one of the worst written pieces of Windows software.

    It wasn't always thus.  I think it went downhill when it started hanging round with MMC.

  22. Gabe says:

    Keep in mind that the audit log only tells you what user opened the file for write access and when. If your users have some app that always requests write access whether it needs it or not, you won't know which user caused the change.

    You also won't know when the changes happen, just when the app opened the file. In fact, if the file was already opened when the auditing was turned on, you can get a change without any audit entries being logged.

    In other words, you can't say "That file was modified at 12:34, so let's check the audit log to see who wrote to the file at 12:34". All you can find out is who had the file open for writing at that time.

  23. anyfoo says:

    Hey, that is pretty cool. Does it incur any performance penalty? I'm not talking about the case where your auditing is so broad that events are generated for almost every single thing, but rather the "normal" case where just a few events are triggered. Is mere checking of the attempted operations and privileges noticeable, or negligible?

  24. 640k says:

    How can I find out which process are trying to find out which process and user is modifying a file?

  25. > Whenver

    > Now you too can look smart

    Heh.

  26. kinokijuf says:

    @John

    > The problem as presented here is not one of security but of troubleshooting.  This is one of those situations where Windows has some built in functionality that, while not specifically designed for a given scenario, can fit the bill if needed.

    I meant that people tend to say that Procmon is better _precisely_ because it is meant for debugging.

Comments are closed.