Windows Server File Share Audit File Attribute Modification

Question

My goal is to identify what user has set the Hidden attribute on a file within the local file share.

I have enabled File Share access auditing as per this article. In short: Added a group policy entry to enable certain accesses to be written to Event Log + enabled auditing on the Folder level for all access types.

As a result, I get such entries in Event Log:

Subject:
    Security ID:        Domain\Username
    Account Name:       Username
    Account Domain:     Domain
    Logon ID:       0x329558

Object:
    Object Server:      Security
    Object Type:        File
    Object Name:        E:\share\filename.xml
    Handle ID:      0xfc4
    Resource Attributes:    S:AI

Process Information:
    Process ID:     0x4
    Process Name:       

Access Request Information:
    Accesses:       WriteAttributes

    Access Mask:        0x100

What attributes exactly did the user set? Is it what is listed in Resource Attributes? They don't look like they mean 'Hidden', and I don't get any other entries in the Event Log of type WriteAttributes (I search thoroughly via PowerShell). And some process is definitely setting this Hidden flag.

Questions:

Does this Event Log entry contain information about the attributes that the application was actually setting?
How else can I track this activity? Process Monitor did not capture a single SetBasicinformationFile event, but the file has still become Hidden!

If you now know which user account (and hence which client workstation) you think might be responsible, you might have better luck running Process Monitor at the client end. — Harry Johnston, Oct 20 '18 at 19:13
@HarryJohnston. Good advice! Sadly, in practice it could have been more than one workstation. And they are also *nix workstations, where CIFS client log is also being very vague. I have also asked for help on the client end ;) https://unix.stackexchange.com/questions/476754/cifs-debugging-not-enough-information — Tony Sepia, Oct 20 '18 at 22:23
The filename doesn't start with a dot by any chance? I could easily imagine a CIFS client deciding that all .foo files should be marked as hidden per the *nix convention. — Harry Johnston, Oct 21 '18 at 01:39
Also, have you been able to confirm whether (a) an existing file is having the hidden attribute set or (b) an existing file is being replaced by a new file that was created with the hidden attribute already set? The `fsutil file queryFileID` command might be useful, if the file is being replaced the ID should change. (I'm thinking you wouldn't see a SetBasicInformationFile event if the hidden flag was set when the file was first created. Also, the new file's temporary name might start with a dot as per my previous comment.) — Harry Johnston, Oct 21 '18 at 01:43
@HarryJohnston, excellent point! So are you saying that a file can be created with a Hidden attribute set already? I will look into this, thank you! — Tony Sepia, Oct 21 '18 at 13:39
Is your main goal to prevent any files from being hidden in a given folder? — Lucky Luke, Oct 21 '18 at 16:43
@LuckyLuke Yes, and we have already revoked permissions to make files hidden from the user in question. It's still happening, which is why I suspect System — Tony Sepia, Oct 21 '18 at 17:24
How did you revoke this? By preventing the "WriteAttributes" right? I've never had to do this, I don't even know whether it's possible to prevent this. I may have an idea for you. For this idea, can I assume that you we can have a starting point where no files are hidden? — Lucky Luke, Oct 21 '18 at 20:36
@LuckyLuke, yes, I think so. No files are hidden at the outset, yes! — Tony Sepia, Oct 23 '18 at 00:14

score 1 · Answer 1 · answered Oct 21 '18 at 15:38

File/Share auditing doesn't provide complete details of what was changed. Resource Attributes is for the Dynamic Access Control feature, to provide granular information about the DAC classification criteria that caused the audit event.

ProcMon on the server may work, but you need to be careful how it is configured. It should be configured to Drop Filtered Events, collect only File events, Save to a Backing File (not Virtual Memory), and the specific Operation (SetBasicInformationFile), and possibly the Path. You would then export the configuration to a PMC file and use that when launching. It's also a good idea to specify a /Runtime in seconds, then move/rename the file when it ends and relaunch, because ProcMon occasionally flakes out and may adversely impact the system.

thank you for clarigying. I have already tried running ProcMon on the server, but I have included absolutely all events, and have done it to memory. Still - no sign of the SetBasicInformationFile event. There is one, but the ProcMon entry doesn't show what exactly has been changed. Is there any way to log what attributes are set? — Tony Sepia, Oct 21 '18 at 20:18

score 1 · Accepted Answer · answered Oct 23 '18 at 05:01

You should be able to accomplish this with a simple batch script where you repeatedly execute dir /b /a:h and then evaluate the errorlevel. The /b switch is optional but shows the directory output in a bare minimum format.

When you run this command, it will return an ERRORLEVEL of 1 when no hidden files are found, which is what you want. If a file is hidden then it will return an ERRORLEVEL of 0, which you don't want, and that's where you can then trigger something.

Now, this won't tell you who hid the file, but if you call it often enough (say every 30 seconds) then you will at least have a time frame as to when it happened, and you should then be able to correlate it with 4663 events that occurred right around that time. I'm assuming you have auditing already on in this folder?

You can call this script with any scheduler, although this is actually a good scenario for the EventSentry Light utility which has a built-in scheduler that can trigger email alerts based on the errorlevel of any script you run. It even includes the output of the script. That feature is called "application scheduler". Of course you can also write your own script and trigger an email with PowerShell, VBScript or something like blat.exe.

The auditing part may be the trickiest if Windows auditing isn't granular enough to catch somebody just hiding a file. But even then auditing on the parent folder should show some activity, like directory listing for example.

Thank you, I like this approach. Sounds like it's just not possible to directly log the event. But proving it 'beyond reasonable doubt' is what this method can certainly achieve. I'm just worried that the 'hiding' part may be an inner working of CIFS share process, but we will see. Thank you! — Tony Sepia, Oct 23 '18 at 22:10

Windows Server File Share Audit File Attribute Modification

2 Answers2