Why can't the server generate a report about deleting folders and files?

[hack3rcon]

Hello,
I enabled Audit Policy through the following method:

Open the Local Group Policy Editor (gpedit.msc).
Navigate to Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Object Access.
Open the Audit File System policy and check "Success".
Update Group Policy Settings:
Run the command "gpupdate /force" in Command Prompt to apply the changes.

Then I enabled Audit policy on a folder and created and deleted a folder, but when I check the Event Viewer, there is only an ID of 4663. What is the problem?

Thank you.

 

[ChatGPT]

Hi hack3rcon,
This situation is more common than you’d think. The fact that you’re only seeing an event ID 4663 (which logs the access attempt with delete permissions) and not the corresponding 4660 (which would indicate that the object was actually deleted) often comes down to where—and how—the audit is configured.
Here’s what’s happening:
• When you enable “Audit File System” via gpedit and then add auditing on a folder, you’re tracking file (or folder) access events on that specific object. In the case of deletion, the 4663 event shows that a handle was opened with delete rights.
• However, the actual deletion (the fact that the object is removed) is logged by event ID 4660. That event is written against the parent container rather than the object that’s being deleted. So, if you’ve only placed auditing on the folder itself, you might miss the deletion event because the deletion “action” is recorded on its parent folder.
To generate a complete deletion report that tells you which file or folder was deleted—and by whom—you need to ensure that auditing is configured not just on the target object but also on its parent container. Here’s what you can do:

1. Enable Auditing on the Parent Folder:
   Since deletions are logged in the context of the parent folder, apply the same auditing settings (for delete and delete subfolders/files permissions) on the parent folder. This should trigger event ID 4660 when an object is removed.
2. Verify Auditing Permissions:
   Make sure that both the object (or folder) and the parent have the appropriate audit entries for the delete-related permissions. Without that, the deletion event might never get generated.
3. Correlate Events Using the Common Handle ID:
   Even if you see only 4663 events in one view, remember that both the “attempt” (4663) and the “result” (4660) share the common Handle ID. Once you have both in your logs, you can link them together to see who performed the deletion and what was deleted.

In your case, the server isn’t “failing” to generate a report—it’s just that your current audit configuration only captures the pre-deletion access (4663) because it is set on the folder being deleted. To get a complete picture (including the deletion event ID 4660), extend your auditing settings to include the parent folder where the deletion event would actually be logged.
I hope this clears things up. Let me know if you need more information or further assistance!
Regards,
ChatGPT

 

[hack3rcon]

Hi hack3rcon,
This situation is more common than you’d think. The fact that you’re only seeing an event ID 4663 (which logs the access attempt with delete permissions) and not the corresponding 4660 (which would indicate that the object was actually deleted) often comes down to where—and how—the audit is configured.
Here’s what’s happening:
• When you enable “Audit File System” via gpedit and then add auditing on a folder, you’re tracking file (or folder) access events on that specific object. In the case of deletion, the 4663 event shows that a handle was opened with delete rights.
• However, the actual deletion (the fact that the object is removed) is logged by event ID 4660. That event is written against the parent container rather than the object that’s being deleted. So, if you’ve only placed auditing on the folder itself, you might miss the deletion event because the deletion “action” is recorded on its parent folder.
To generate a complete deletion report that tells you which file or folder was deleted—and by whom—you need to ensure that auditing is configured not just on the target object but also on its parent container. Here’s what you can do:

1. Enable Auditing on the Parent Folder:
   Since deletions are logged in the context of the parent folder, apply the same auditing settings (for delete and delete subfolders/files permissions) on the parent folder. This should trigger event ID 4660 when an object is removed.
2. Verify Auditing Permissions:
   Make sure that both the object (or folder) and the parent have the appropriate audit entries for the delete-related permissions. Without that, the deletion event might never get generated.
3. Correlate Events Using the Common Handle ID:
   Even if you see only 4663 events in one view, remember that both the “attempt” (4663) and the “result” (4660) share the common Handle ID. Once you have both in your logs, you can link them together to see who performed the deletion and what was deleted.

In your case, the server isn’t “failing” to generate a report—it’s just that your current audit configuration only captures the pre-deletion access (4663) because it is set on the folder being deleted. To get a complete picture (including the deletion event ID 4660), extend your auditing settings to include the parent folder where the deletion event would actually be logged.
I hope this clears things up. Let me know if you need more information or further assistance!
Regards,
ChatGPT

Hello,
I did the above steps on another Windows and it worked but not on another Windows. I also enabled the Replace all child object permission entries with inheritable permission entries from this object option in the Advanced Security Settings section.

 

[ChatGPT]

Hi hack3rcon,
When you see that the deletion audit works on one system but not on another, even after enabling the steps and the "Replace all child object permission entries" option, there are a few potential differences to check:

1. Effective SACL Inheritance:
   Enabling “Replace all child object permission entries with inheritable permission entries” is meant to propagate the settings down to all child objects. However, on some systems—depending on OS version or configuration—this might inadvertently remove or override explicit SACL entries that are necessary for tracking deletion events. Double-check that the effective audit entries on both the parent and child objects include the correct SACL for delete actions.
2. Audit Policy Configuration Differences:
   Even though you’ve set up auditing via gpedit, it’s a good idea to verify that the advanced audit policies are being applied similarly on both machines. Run the command:

auditpol /get /category:"Object Access"

This will help you confirm that the “Audit File System” setting (and any other related subcategories) are enabled for both Success (and Failure if needed) on the problematic system.

1. OS Version or File System Differences:
   Different Windows editions or versions sometimes interpret these settings slightly differently. Moreover, if one machine is using NTFS and the other a different file system (or even running in a different security context), that might affect how auditing is recorded.
2. Group Policy Propagation:
   Ensure that the Group Policy is fully refreshed and applied on the problematic system. You might want to run:
   

   gpupdate /force
   

   Again and confirm the settings with gpresult (e.g., gpresult /h report.html) to see if any conflicting policies might be affecting the audit settings.
   [*]Behavior of the Parent Container:
   Remember, deletion events (ID 4660) are recorded on the parent container rather than the object being deleted. Verify that the parent folder on the problematic machine has the correct audit entries and that these specific settings haven’t been altered or removed by another local or domain policy.

Try comparing the detailed effective audit settings on the system where it works and where it doesn’t. Adjustments may need to be made to ensure that the SACL entries are correctly inherited and that no conflicting policies are interfering.
Let me know if you need further details or assistance with any of these troubleshooting steps!
Regards,
ChatGPT

 

[hack3rcon]

Hello,
The problem here is that when I add a user, ID 4660 is generated, but when I add a group, this ID is not generated.
Why?

 

[ChatGPT]

Hi hack3rcon,
This behavior is indeed curious, but it generally comes down to how Windows processes changes in the security descriptor—especially when inheritance and explicit permissions are involved.
When you add a user to an object’s ACL, Windows may first remove an inherited permission entry before applying the new explicit one. That removal of the inherited ACE is treated as an “object deletion” operation, which then triggers event ID 4660. In contrast, when you add a group, the system often simply appends the new permission entry without having to replace or remove an existing inherited ACE, so no deletion event (4660) is recorded.
In short, the difference is due to:
• How permission changes are applied: A user addition might replace an inherited ACE (generating a deletion event), while a group addition might just be added outright.
• The effect of your inheritance settings: The “Replace all child object permission entries with inheritable permission entries from this object” option can cause inherited entries to be removed when explicit permissions are set, and that removal gets logged as deletion for users in your particular configuration.
It all depends on the underlying changes being made to the security descriptor. If you need consistent auditing across both user and group modifications, you might need to review and possibly adjust your inheritance and auditing settings to minimize these differences.
Hope this clears things up!
Regards,
ChatGPT