While there are many distinct types of breaches, incident responders seek one thing in common: traces of an attacker. After every attack, hackers will leave their footprint in either way. So, we hunt for traces in memory, on the network, or within any of several filesystem artifacts on disc in digital forensics. Even though many artifacts exist, Windows event logs will provide the most bang for the buck on endpoints. This is what incident responders most typically request, whether raw or formatted from which will be ingested into a SIEM.
Monitoring the file access and registry access is one of the best ways to identify the attack or breaches. One of the Event IDs which is more helpful for SOC analysts while investigating the alert is 4663.
Event ID 4663:
Windows Security message ID 4663 is detecting evidence of a process created, by the creation of a file in the Windows Prefetch directory.
Event 4663 is logged when a particular operation is performed on an object. This object could be of any type, such as, file system, kernel, registry object, or a file system object that resides on a removable storage device. 4663 doesn’t have failure events and shows that the access right was used, instead of just showing that it was requested.
Log Field Explanation:
Security ID : SID of account that accessed the object, note that SIDs are automatically resolved by event viewer if the user still exists, otherwise the SID is shown.
Account Name : The account name that accessed the object
Account Domain : The subject’s domain or computer name (for non-domain members). For well-known security principals like LOCAL SERVICE, the value is NT AUTHORITY
Logon ID : The Logon ID of the user session, can be correlated with other logon events, e.g. event 4624.
Object Server : Value is always Security
Object Type : The object type that was accessed and audited.
Object Name : The (unique) name of the object that was accessed, for File object types this would be the file name (path).
Handle ID : The handle to the object name can be correlated with other events, e.g. 4656.
Accesses : File System Objects Access Rights code will be logged here.
AccessMask : The hexadecimal representation of all accesses listed in AccessList.
Process ID : The PID of the processes which performed access to the object. For files accessed from the network (via a file share), the value is often 0x4, the “NT Kernel & System” process which essentially acts as a proxy on behalf of a remote request.
Process Name : The name of the process which operated. This field is empty of the operation affected a file and originated from a remote host through a file share (see Process ID).
ResourceAttributes : Shows resource attributes associated with the object.
Access code list:
File System Objects Access Rights
| Code | Name | Description |
| 0x1 | ReadData (or ListDirectory) | ReadData: For a file object, the right to read the corresponding file data. For a directory object, the right to read the corresponding directory data. ListDirectory: For a directory, the right to list the contents of the directory. |
| 0x2 | WriteData (or AddFile) | WriteData: For a file object, the right to write data to the file. For a directory object, the right to create a file in the directory (FILE_ADD_FILE). AddFile: For a directory, the right to create a file in the directory. |
| 0x4 | AppendData (or AddSubdirectory or CreatePipeInstance) | AppendData: For a file object, the right to append data to the file. (For local files, write operations will not overwrite existing data if this flag is specified without FILE_WRITE_DATA.) For a directory object, the right to create a subdirectory (FILE_ADD_SUBDIRECTORY). AddSubdirectory: For a directory, the right to create a subdirectory. CreatePipeInstance: For a named pipe, the right to create a pipe. |
| 0x8 | ReadEA | The right to read extended file attributes. |
| 0x20 | Execute (or Traverse) | Execute: For a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter. Traverse: For a directory, the right to traverse the directory. By default, users are assigned the BYPASS_TRAVERSE_CHECKING privilege, which ignores the FILE_TRAVERSE access right. See the remarks in File Security and Access Rights for more information. |
| 0x40 | DeleteChild | For a directory, the right to delete a directory and all the files it contains, including read-only files. |
| 0x80 | ReadAttributes | The right to read file attributes. |
| 0x100 | WriteAttributes | The right to write file attributes. |
| 0x10000 | DELETE | The right to delete the object. |
| 0x20000 | READ_CONTROL | The right to read the information in the object’s security descriptor, not including the information in the system access control list (SACL). |
| 0x40000 | WRITE_DAC | The right to modify the discretionary access control list (DACL) in the object’s security descriptor. |
| 0x80000 | WRITE_OWNER | The right to change the owner in the object’s security descriptor |
| 0x100000 | SYNCHRONIZE | The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Some object types do not support this access right. |
| 0x1000000 | ACCESS_SYS_SEC | The ACCESS_SYS_SEC access right controls the ability to get or set the SACL in an object’s security descriptor. |
Benefits of monitoring the Event ID 4663:
- It will detect unauthorized attempts to access files and folders.
- It will detect unusual and possibly malicious behavior.
- It will monitor Access Request Information, such as WriteData, AppendData, WriteEA, DeleteChild, WriteAttributes, DELETE, WRITE_DAC, and WRITE_OWNER
- It will prevent the abusing of privileges.
- It can detect lateral movement attacks and zerologon attacks.
Also Read: DNS sinkholes to Prevent Malware? How did it work?
Drawback:
- This event is triggered when access permissions are logged when an object is opened. No matter how many times the permissions are exercised while the object is opened, only the first occurrence is logged.
- More false positives will be triggered if a Splunk rule is enabled based on it. Need to specify the exact folders or files or location that needs to be monitored.
FILE AUDITING with 4663(Object monitoring: Security):
Event Code 4663 will capture when a new file is added, modified, or deleted. File auditing must be enabled on the directories you want to monitor and the new files.
Sample Query for 4663 to Filter out/exclude known good noise:
index=wineventlog EventCode=4663 (Process_Name=*powershell.exe) NOT (Process_Name=”\\Windows\\servicing\\Trusted Installer.exe” OR “\\Windows\\System32\\poqexec.exe”) NOT (Object_Name=”*\\Users\\svc_acct\\pnp” OR Object_Name=”C:\\Users\\Surf\\AppData\\Local\\Google\\Chrome\\User Data*” NOT Object Name=”C:\\Users\\Surf\\AppData\\Roaming\\Microsoft\\Windows\\Recent\\Custom Destinations”) NOT (Object_Name=”C:\\Windows\\System32\\Log Files\\*” OR Object Name=”ProgramData\\Microsoft\\RAC\\” OR Object_Name=”\\Microsoft\\Windows\\Explorer\\thumbcache” OR Object_Name=”*.MAP” OR Object_Name=”*counters.dat” OR Object_Name=”\\Windows\\Gatherlogs\\System Index\\”) | rename Process_Name AS “Created By” | table _time, host, Security_ID, Handle_ID, Object_Type, Object_Name, Process_ID, Created_By, Accesses
Mimikatz Detection Using PowerShell And EventCode 4663:
The attacker’s most commonly used tool in Powershell. It is very important to monitor events along executed from Powershell.
This search looks for Windows Event Code(signature_id) 4663 (object access), where the process performing the access is PowerShell.exe, the target process of the access is lsass.exe, and the access mask is given as 0x10. This is consistent with the use of PowerShell to execute Mimikatz using sekurlsa::logonpasswords. It will return the host where the activity occurred, the process and associated id, the enabled privilege, and the message in the event.
index=wineventlog EventCode=4663 Process_Name=*/powershell.exe Object_Name=* System32\lsass.exeAccess_Mask=0x10 | table _time, host, Security_ID, Handle_ID, Object_Type, Object_Name, Process_ID, Created_By, Accesses
Note: Need to fill the exact file location at the wildcard.
Using the Windows Security Log to track removable storage:
Windows Security Log does offer a way to audit removable storage access. Removable storage auditing in Windows works similarly to and logs the same events as File System auditing. The difference is in controlling what activity is audited.
To review, with File System auditing, there are 2-levels of audit policy. First, we need to enable the Audit File System audit subcategory at the computer level. Then need to choose which folders we wish to audit and enable object-level auditing on those folders for the users/groups, permissions, and success/failure results that need to be monitored.
However, Removable Storage auditing is much simpler to enable and far less flexible. After enabling the Removable Storage audit subcategory (see below) Windows begins auditing all access requests for all removable storage. It’s equivalent to enabling auditing Full Control for Everyone.
Once enabled, Windows logs the same event ID 4663 as for File System auditing. For example, the event below shows that user SpecialAgent007 wrote a file called SecretGadgets.docx to a removable storage device Windows arbitrarily named \Device\HarddiskVolume12 with the program named Explorer (the Windows desktop).
How can I tell if this is a removable storage event rather than a regular File System audit?
After all, it’s the same event ID as used for normal file system auditing. Notice the Task Category above which says Removable Storage. The information under Subject tells who acted. Object Name gives the name of the file, relative path on the removable storage device and the arbitrary name Windows assigned the device the first time it was connected to this system. Process information indicates the program used to perform the access. To understand what type of access (e.g. Delete, Write, Read) was performed look at the Accesses field which lists the permissions used.
If we need to track the information being copied from the network to removable storage devices we should enable Audit Removable Storage via group policy on all the endpoints. Then monitor for Event ID 4663 where Task Category is Removable Storage and Accesses is wither WriteData or AppendData.
Also Read: Latest IOCs – Threat Actor URLs , IP’s & Malware Hashes
Conclusion:
If malware puts its dirty fingers on a key in the registry, a network share, or removable storage, object monitoring will log that operation. Forensic timelining accessed files, executables, directories, and network shares add context to what we already know. Enabling object audit functionalities dramatically increases the log volume. So, we need to make a wise decision.