Sure thing.
I am trying to implement three use cases.
1) Windows event ID: Failed object access attempt by a subject "Subject"
(tied to a real user, not a system account) of Object Type: File and
object: "C:\Users\Other-than-Subject\Whatever-else comes after.ext". Ten
recurrences by same Subject --> trigger an e-mail alert.
Here's what the event look like. The content of all the fields is decoded
in Wazuh fork of OSSEC.
2017 Mar 02 04:04:22 WinEvtLog: Security: AUDIT_FAILURE(4656): Microsoft-
Windows-Security-Auditing: (no user): no domain: Desktop: A handle to an
object was requested. Subject: Security ID:
S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Account Name: Subject1
Account Domain: DESKTOP Logon ID: 0xXXXXX Object: Object Server: Security
Object Type: File Object Name: C:\Users\Subject2\Documents\Private.txt
Handle ID: 0xXXX Resource Attributes: - Process Information: Process ID:
0xXXX Process Name: C:\Windows\System32\notepad.exe Access Request
Information: Transaction ID: {00000000-0000-0000-0000-000000000000}
Accesses: SYNCHRONIZE ReadData (or ListDirectory) Access Reasons:
SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;BU) ReadData (or ListDirectory):
Granted by D:(A;;0x1200a9;;;BU) Access Mask: 0x100001 Privileges Used for
Access Check: - Restricted SID Count: 0
During decoding, the values of Account Name are stored as "subject", Object
Name as "object", the main directory in object as obj_dir_1, and first
subdirectory as obj_dir_2. In the example above obj_dir_1 is "Users" and
obj_dir_2 is "Subject2".
Practically, if an event similar to the above occurs where the value of
obj_dir_1 is "Users" *and* the value of decoded field "subject" does *not*
match the value of decoded field "obj_dir_2" ten times in half an hour from
same subject trigger an e-mail alert.
2) User successfully accessing files in the home folder of another user -->
A single occurrence generates an *immediate *e-mail alert.
2017 Mar 02 04:04:22 WinEvtLog: Security: AUDIT_SUCCESS(4656): Microsoft-
Windows-Security-Auditing: (no user): no domain: Desktop: A handle to an
object was requested. Subject: Security ID:
S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Account Name: Subject1
Account Domain: DESKTOP Logon ID: 0xXXXXX Object: Object Server: Security
Object Type: File Object Name: C:\Users\Subject2\Documents\Private.txt
Handle ID: 0xXXX Resource Attributes: - Process Information: Process ID:
0xXXX Process Name: C:\Windows\System32\notepad.exe Access Request
Information: Transaction ID: {00000000-0000-0000-0000-000000000000}
Accesses: SYNCHRONIZE ReadData (or ListDirectory) Access Reasons:
SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;BU) ReadData (or ListDirectory):
Granted by D:(A;;0x1200a9;;;BU) Access Mask: 0x100001 Privileges Used for
Access Check: - Restricted SID Count: 0
Practically, if a single event similar to the above occurs where the value
of subject does *not* match the value of obj_dir_2 *and* obj_dir_1 is
"Users" trigger an e-mail alert.
Use case 1 is a security incident that can be described as: repeated failed
attempts at unauthorized object access by user.
Use case 2 is a more serious security incident: confirmed successful
unauthorized object access by user due to a loophole in the access control
list on Object. If subject1 is a *privileged *account, this is a clear
abuse of privilege by a system administrator.
Use Case 3 is an even more serious incident: one or more use case 1
followed by use case 2. Subject successfully managed to modify the ACL on
Object (then we would expect to see evidence thereto in the logs in terms
of changed permissions events -- another use case) or managed to subvert or
bypass the access control mechanism.
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
