Clear Operating System Logs

A subject clears system logs to hide evidence of their activities.

A subject clears MacOS system logs to hide evidence of their activities.

MacOS system logs store various types of information, such as system events, errors, application launches, network activity, and user authentication activities.

MacOS system logs are stored in /private/var/log.

A subject clears Windows Event logs to conceal evidence of their activities.

Windows Event Logs store various types of information, such as system errors, application events, security auditing messages, and other operational events.

The logs are stored in C:/WINDOWS/system32/config.

Windows Event Logs can be cleared using the Event Viewer utility, provided the user account has administrative privileges.

The Principle of Least Privilege should be enforced, and period reviews of permissions conducted to ensure that accounts have the minimum level of access required to complete duties as per their role.

An agent capable of Endpoint Detection and Response (EDR) is a software agent installed on organization endpoints (such as laptops and servers) that (at a minimum) records the Operating System, application, and network activity on an endpoint.

Typically EDR operates in an agent/server model, where agents automatically send logs to a server, where the server correlates those logs based on a rule set. This rule set is then used to surface potential security-related events, that can then be analyzed.

An EDR agent typically also has some form of remote shell capability, where a user of the EDR platform can gain a remote shell session on a target endpoint, for incident response purposes. An EDR agent will typically have the ability to remotely isolate an endpoint, where all network activity is blocked on the target endpoint (other than the network activity required for the EDR platform to operate).

Detailed PowerShell logging is not enabled by default and must be configured.

PowerShell is able to record the processing of commands, script blocks, functions, and scripts whether invoked interactively, or through automation.

PowerShell logging can be enabled through Group Policy with the following: Administrative Templates → Windows Components → Windows PowerShell

There are 3 available logging types, they are: Module Logging, Script Block Logging and Transcription.

Module Logging: Records pipeline execution details, such as variable initialisation and command invocations, capturing portions of scripts and some de-obfuscated code. This logging is available since PowerShell 3.0 and generates a large volume of events, providing valuable output not captured elsewhere. Events are written to Event ID 4103.

Module logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging \ModuleNames → * = *

Script Block Logging: Captures blocks of code as they are executed, including de-obfuscated code, allowing visibility into the full contents of executed scripts and commands. This feature is available in PowerShell 5.0 and records events under Event ID 4104.

Script block logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1

Transcription: Records the input and output of entire PowerShell sessions, providing a comprehensive record of all commands executed and their results.

Transcription logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)

By autonomously collecting log files from a system and transporting them to another system, such as a SIEM collector, they are typically no longer accessible by the subject, preventing them from being able to delete them. These can aid in investigations where a subject has deleted local logs.

Windows Event Log ID 4660 “An object was deleted” is generated when an object was deleted, such as a file system, kernel, or registry object. This Event is not enabled by default, and requires “Delete” auditing to be enabled in the object’s System Access Control List (SACL). This event doesn’t contain the name of the deleted object, so investigators must also utilize Event ID 4663.

Windows Event Log ID 4663 “An attempt was made to access an object” can be used in combination with Event ID 4660 to track object deletion. This Event is not enabled by default, and requires “Delete” auditing to be enabled in the object’s System Access Control List (SACL).

This may represent an anti-forensics technique if there is no reasonable explanation for why the objected was deleted from the system.

Windows Event Log ID 1102 “The audit log was cleared” is generated when the Windows Security audit log has been cleared. This Event contains the account's SID, name, and domain that cleared the log.

This may represent an anti-forensics technique if there is no reasonable explanation for why the Event Log was cleared on this system.