Why do you want to monitor who accessed a particular file?

Files are one of the primary forms of storing information. It is common practice for companies to store data in files that hold valuable, sometimes sensitive, information. What could this "important" data be? Of course, I am not talking about the company’s last team-building pictures. I’m afraid that’s not what the bad guys are interested in. They will likely be more interested in business plans, financial or personal data.

Besides that, it’s important to see who is acting suspicious within your organization. There are numerous security reasons why you would like to see who accessed or tried to access a particular file or folder.

Monitor assignment of secure access controls

Almost all compliance mandates start with putting protection in place around files containing sensitive data. Questions you may ask:

  • Are the correct permissions assigned for the job role?

  • Is the proper user or group selected during the permission assignment?

  • Are the users attempting to make changes that they are allowed to do so?

Monitor access to and usage of protected data

Compliance is a continual journey where IT must ensure their environment adheres to certain regulations. Your security team should have continuous visibility of who is accessing files, when, and from where. Having this information in real-time is paramount to remaining vigilant against inappropriate access by malicious insiders and external attackers.

Measure access control strength

It’s unfortunate but common for IT to allow Active Directory to evolve organically. Group memberships are rarely attested to, let alone permissions and nested group memberships checked, resulting in users having over-permissions and having access to data they should not have.

Detect breaches

While organizations want to avoid a data breach (and, therefore, a compliance breach), it remains a possibility. Thankfully, as long as the data resides on a Windows file server, there will be definite indicators. If your logging setup is correct, you should be able to discover abnormalities in file activity, like non-standard access times or large amounts of data accessed in a short period.

Enabling file auditing on Windows

There are two simple things you need to do in Windows.

  • Enable Audit Object Access via a Group Policy Object

  • Enable file auditing on a file or folder you want to monitor

Enabling Audit Object Access via a Group Policy Object

You can configure this security setting by opening the appropriate policy under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

enabling audit object access
Figure 1. Enabling Audit Object Access in Windows
Note
 The above image shows a Local Group Policy Editor in Windows 10. The settings are the same in an Active Directory environment where policy is made domain or forest-wise.

Enabling file auditing on a file or folder you want to monitor

There is a great and simple explanation in the Microsoft documentation about how to enable file auditing on specific files or folders. See, Apply a basic audit policy on a file or folder.

Enabling file auditing will allow the operating system to add two events to the Windows Event Log: Event ID 4663 and Event ID 4656. I will focus on these two events here; specifically, how to get the required information out of these in a way that is easy to understand and process further.

  • Event ID 4663 - An attempt was made to access an object.

  • Event ID 4656 - A handle to an object was requested.

There is official documentation and explanation in the Microsoft documentation about them: Event ID 4663 and Event IT 4656.

How can NXLog help you in auditing your files?

Once you finish the above and the events in question are present in the Windows Event Log, you can fire up NXLog Enterprise Edition and see what these logs look like when collected. For testing, let’s collect the log record with all the original data and see what information is available.

Example 1. Collecting Event ID 4663 in its original form

This configuration collects Event ID 4656 and Event ID 4663 as is. I only set the configuration to present the output in JSON format so the data is more readable. JSON is also an excellent choice if you want to process it further.

<Extension json>
    Module         xm_json
    PrettyPrint    TRUE
</Extension>

<Input fileaudit>
    Module         im_msvistalog
        <QueryXML>
            <QueryList>
            <Query Id="0" Path="Security">
            <Select Path="Security">*[System[(EventID=4656 or EventID=4663)]]</Select>
            </Query>
            </QueryList>
        </QueryXML>
</Input>

The output is in JSON format. As you can see, the result includes too much information for our needs. Nevertheless, it is a good example; I will eliminate the unnecessary fields in my next example.

{
    "EventTime": "2023-05-02T00:51:53.200993-07:00",
    "Hostname": "IMPORTANT-COMPUTER",
    "Keywords": "9232379236109516800",
    "LevelValue": 0,
    "EventType": "AUDIT_SUCCESS",
    "SeverityValue": 2,
    "Severity": "INFO",
    "EventID": 4663,
    "SourceName": "Microsoft-Windows-Security-Auditing",
    "ProviderGuid": "{54849625-5478-4994-A5BA-3E3B0328C30D}",
    "Version": 1,
    "TaskValue": 12800,
    "OpcodeValue": 0,
    "RecordNumber": 866208,
    "ExecutionProcessID": 4,
    "ExecutionThreadID": 7792,
    "Channel": "Security",
    "Message": "An attempt was made to access an object.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-12-1-3226568308-1140053887-2796057524-3382768311\r\n\tAccount Name:\t\tJohnDoe\r\n\tAccount Domain:\t\tNXLog\r\n\tLogon ID:\t\t0x3D62A\r\n\r\nObject:\r\n\tObject Server:\t\tSecurity\r\n\tObject Type:\t\tFile\r\n\tObject Name:\t\tC:\\test\r\n\tHandle ID:\t\t0x2960\r\n\tResource Attributes:\tS:AI\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x11a0\r\n\tProcess Name:\t\tC:\\Windows\\explorer.exe\r\n\r\nAccess Request Information:\r\n\tAccesses:\t\tReadData (or ListDirectory)\r\n\t\t\t\t\r\n\tAccess Mask:\t\t0x1",
    "Category": "File System",
    "Opcode": "Info",
    "Level": "Information",
    "SubjectUserSid": "S-1-12-1-3226568308-1140053887-2796057524-3382768311",
    "SubjectUserName": "JohnDoe",
    "SubjectDomainName": "NXLog",
    "SubjectLogonId": "0x3d62a",
    "ObjectServer": "Security",
    "ObjectType": "File",
    "ObjectName": "C:\\test",
    "HandleId": "0x2960",
    "AccessList": "%%4416\n\t\t\t\t",
    "AccessMask": "0x1",
    "ProcessId": "0x11a0",
    "ProcessName": "C:\\Windows\\explorer.exe",
    "ResourceAttributes": "S:AI",
    "EventReceivedTime": "2023-05-02T00:51:54.825393-07:00",
    "SourceModuleName": "fileaudit",
    "SourceModuleType": "im_msvistalog"
}
Example 2. Collecting Event ID 4663 and trimming the event fields

This configuration builds on the previous one. It collects the same Event IDs, but I added the xm_rewrite module to trim unnecessary fields and only retain the fields we need. This is important not only from the manageability point of view but from the perspective of data storage size on large scales.

Within the xm_rewrite module, the Keep directive is used to keep the selected fields, and the Rename directive is utilized to rename some of the fields to more obvious ones.

At the end of the im_msvistalog module block, I included a line to instruct the module to use the configuration in the xm_rewrite module block to process the data.

The renaming might not be suitable for your environment, and I solely used the naming to represent the possibilities that NXLog Enterprise Edition can give you.

<Extension json>
    Module         xm_json
    PrettyPrint    TRUE
</Extension>

<Extension rewrite>
    Module         xm_rewrite
    Keep           EventTime ,Hostname, EventType, EventID, Category, SubjectUserName, SubjectDomainName, ObjectType, ObjectName,
    Rename         EventTime, When 
    Rename         Hostname, Where
    Rename         EventType, Result
    Rename         SubjectUserName, Who
    Rename         SubjectDomainName, DomainName
</Extension>

<Input fileaudit>
    Module         im_msvistalog
        <QueryXML>
            <QueryList>
            <Query Id="0" Path="Security">
            <Select Path="Security">*[System[(EventID=4656 or EventID=4663)]]</Select>
            </Query>
            </QueryList>
        </QueryXML>
    Exec           rewrite->process();
</Input>

The output is in JSON format but very different from the previous one. With a simple configuration change, I filtered out what was unnecessary in our case. The example speaks for itself; you can see how much more readable it is.

In addition, the difference between the two output files is 1.9kB versus 278 bytes (on my file system), the latter being seven times smaller than the former. Think about your last SIEM invoice; you’ll then understand why the size of log files matter, and how NXLog Enterprise Edition can make a huge difference in the cost of log management.

{
    "When": "2023-04-27T22:52:26.138469-07:00",
    "Where": "IMPORTANT-COMPUTER",
    "Result": "AUDIT_SUCCESS",
    "EventID": 4663,
    "Category": "File System",
    "Who": "JohnDoe",
    "DomainName": "NXLog",
    "ObjectType": "File",
    "ObjectName": "C:\\test"
}

Conclusion

Apart from restating the obvious that monitoring file access is paramount, it is also relatively simple with the right tool. With NXLog Enterprise Edition, you can easily extract the data from Windows Event Log, trim out the noisy data, and at the same time do the finance department a favor by reducing the size of data you send to your SIEM.

Tip
 You can also use the techniques described here to trim any other entries from the Windows Event Log.

NXLog Platform is an on-premises solution for centralized log management with
versatile processing forming the backbone of security monitoring.

With our industry-leading expertise in log collection and agent management, we comprehensively
address your security log-related tasks, including collection, parsing, processing, enrichment, storage, management, and analytics.

Start free Contact us
Share
Related Posts