Blog

Improving Your Blue Team’s Ability To Detect Threats With Enhanced Siem Telemetry

SIEM, Threat Research

By Aaron Beardslee, Lead Cyber Threat Hunter, Tim Peck, Senior Security Research Engineer

Blue Teams are tasked with threat hunting and as part of a Blue Team research organization, we understand how every advantage can be helpful. Our research lab uses the logging approach described in this article to detect cutting edge malware, Red Team tooling and modern attack techniques such as Sliver C2, Villain / Hoaxshell, AD Manipulation / Enumeration, and various social engineering attacks. We have found this strategy to be effective and are sharing what has worked for us.

Setting up your logging profile

A logging profile set up with a baseline of ingested sources is the first step. This section describes the configuration settings on our domain controllers (DCs), endpoints, and servers. Some of the following sections are specific to specialized attack techniques and the logging required to detect that specific attack.

To have the most success at detecting advanced Red Team or threat actor TTPs, deploying Sysmon, PowerShell, and the Windows GPOs below on the targeted workstations and servers is critical. If log volume is an issue, do not deploy Sysmon or enable PowerShell on domain controllers since adversarial tactics start on perimeter systems and travel inward to the DCs.

Securonix senior threat researchers developed the following script to quickly deploy this logging profile.

Note: Tweak the script to modify GPOs. For example, audit access logs are noisy, so those lines can be deleted/commented.

Sysinternals Sysmon — servers and workstations

System Monitor (Sysmon) is a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows Event Log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network.

Note that Sysmon does not provide analysis of the events it generates, nor does it attempt to protect or hide itself from attackers.

Overview of Sysmon capabilities

Sysmon includes the following capabilities:

Logs process creation with a full command line for both current and parent processes.
Records the hash of process image files using SHA1 (the default), MD5, SHA256 or IMPHASH.
Multiple hashes can be used at the same time.
Includes a process GUID in process create events to allow for correlation of events even when Windows reuses process IDs.
Includes a session GUID in each event to allow correlation of events on the same logon session.
Logs loading of drivers or DLLs with their signatures and hashes.
Logs opens for raw read access of disks and volumes.
Optionally logs network connections, including each connection’s source process, IP addresses, port numbers, hostnames and port names.
Detects changes in file creation time to understand when a file was really created. Modification of file create timestamps is a technique commonly used by malware to cover its tracks.
Automatically reload configuration if changed in the registry.
Rule filtering to include or exclude certain events dynamically.
Generates events from early in the boot process to capture activity made by even sophisticated kernel-mode malware.

Sysinternals: Sysmon — installation

Run CMD/PowerShell with administrator rights
sysmon.exe -accepteula -i sysmonconfig.xml

Update existing configuration

Run CMD/PowerShell with administrator rights
sysmon.exe -c sysmonconfig.xml

Uninstall/Reinstall

(Recommended in current Sysmon deploys running an older version of Sysmon)

Run CMD/PowerShell with administrator rights
Sysmon.exe -u
sysmon.exe -accepteula -i sysmonconfig.xml

Note: on 64-bit systems use the sysmon64.exe binary, and replace the above commands with “sysmon64.exe”

See Appendix A for Deployment and Configuration scripts

Windows logging high telemetry domain policy — servers and workstations

The following settings are the default Audit Policies used in one of our malware detonation chamber labs for high visibility feedback from our servers and workstations. This configuration is modified specifically in our Default Domain Policy but can be targeted to specific systems using GPOs.

Step 1: Start setting up Audit Policies with Account Logon

Step 2: Set up Account Management

Step 3: Next is Detailed Tracking

Step 4: Check DS Access

Step 5: Logon/Logoff

Note: The “Audit Filtering Platform Connection” Subcategory is extremely noisy and not entirely necessary if Sysmon with Event ID 3 is installed on the monitored section of the domain

Step 6: Object Access

Step 7: Policy Change

Step 8: Privilege Use

Step 9: System

Note: We typically rely on Sysmon Event ID 12 and 13 for registry events

Step 10: Global Object Access Auditing

Windows logging command line auditing – EventID 4688 – servers and workstations

Computer Configuration > Policies > Administrative Templates: Policy Definitions > System > Audit Process Creation

This policy setting determines what information is logged in security audit events when a new process has been created.

This setting only applies when the Audit Process Creation policy is enabled. If you enable this policy setting the command line information for every process will be logged in plain text in the security event log as part of the Audit Process Creation event 4688, “a new process has been created,” on the workstations and servers on which this policy setting is applied.

If you disable or do not configure this policy setting, the process’s command line information will not be included in Audit Process Creation events.

Default: Not configured

Step 11: Enable Windows Logging Command Line Auditing, EventID 4688 for Servers and Workstations

PowerShell logging — servers and workstations

Module Logging

Module logging records pipeline execution details as PowerShell executes, including variable initialization and command invocations. Module logging will record portions of scripts, some de-obfuscated code, and some data formatted for output. This logging will capture some details missed by other PowerShell logging sources, though it may not reliably capture the commands executed. Module logging has been available since PowerShell 3.0. Module logging events are written to Event ID (EID) 4103.

To enable module logging:

In the “Windows PowerShell” GPO settings, set “Turn on Module Logging” to enabled.
In the “Options” pane, click the button to show Module Name.
In the Module Names window, enter * to record all modules.

Optional: To log only specific modules, specify them here. (Note: this is not recommended.)

Click “OK” in the “Module Names” window.
Click “OK” in the “Module Logging” window.

Alternately, setting the following registry values will have the same effect:

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

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

Step 12: Enable module logging by following the steps listed.

Script block logging

Script block logging records blocks of code as they are executed by the PowerShell engine, thereby capturing the full contents of code executed by an attacker, including scripts and commands. Due to the nature of script block logging, it also records de-obfuscated code as it is executed. For example, in addition to recording the original obfuscated code, script block logging records the decoded commands passed with PowerShell’s -EncodedCommand argument, as well as those obfuscated with XOR, Base64, ROT13, encryption, etc., in addition to the original obfuscated code. Script block logging will not record output from the executed code. Script block logging events are recorded in EID 4104. Script blocks exceeding the maximum length of an event log message are fragmented into multiple entries. A script is available to parse script block logs and reassemble fragmented blocks (see reference 5).

To enable script block logging:

In the “Windows PowerShell” GPO settings, set “Turn on PowerShell Script Block Logging” to enabled.

Alternately, setting the following registry value will enable logging:

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

Step 13: Next enable script block logging

Detecting specific attack techniques: remote SAM dump and Certipy REQ

Certain attacks used by Red Teams or threat actors will generate very unique auditing artifacts. The goal of this section is to highlight what is required to detect some of these specialized attacks with customized and specific auditing enabled. We chose these two techniques to demonstrate examples of…

Remote SAM dump

resourcetype = “Microsoft Windows SNARE” and eventid=4663 and eventdata contains “winreg”

Note: This requires an ACL enabled on the winreg key of the targeted server for the 4663 events to pick up the remote registry service starting.

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

https://riccardoancarani.github.io/2020-05-10-hunting-for-impacket/#secretsdumppy

https://www.praetorian.com/blog/how-to-detect-and-dump-credentials-from-the-windows-registry/

index= activity and resourcegroupname contains “Windows” and eventid=4663 and eventdata = “\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\SecurePipeServers\winreg” and sourceprocessname = “svchost.exe”

index= activity and resourcetype = “Microsoft Windows SNARE” and eventid=4663 and eventdata contains “winreg”

Step 14: Configure Remote SAM Dump

Certipy

Certipy is an offensive tool for enumerating and abusing Active Directory Certificate Services (AD CS). If you’re not familiar with AD CS and the various domain escalation techniques, we highly recommend reading Certified Pre-Owned by Will Schroeder and Lee Christensen. https://github.com/ly4k/Certipy

Certipy req

Certipy ‘req’ command requests certificates over RPC and the authentication is completed with NTLM over SMB for this phase. This stage also generates a 4886 (Certificate Services received a certificate request) event followed by a 4887 (Certificate Services approved a certificate request and issued a certificate) event. To enable these logs requires quite a bit of setup on the Certificate Authority server assigned the AD Certificate Services role.

Step 15.1: Setting up CERTIPY REQ

Step: 15.2

Step: 15.3

Certipy log samples

Step 16: Sample Certipy logs

APPENDIX A – DEPLOYMENT SCRIPT AND SYSMONCONFIG.XML

Batch script for auto deployment from SYSVOL

tasklist | findstr /i sysmon

IF %ERRORLEVEL% EQU 0 GOTO :Uninstall

IF %ERRORLEVEL% EQU 1 GOTO :Install

:Install

“\\<YOUR DOMAIN HERE>\sysvol\<YOUR DOMAIN HERE>\Sysmon\Sysmon64.exe” -accepteula -i “\\<YOUR DOMAIN HERE>\sysvol\<YOUR DOMAIN HERE>\Sysmon\sysmonconfig.xml”

GOTO :StartService

:StartService

net start Sysmon64

GOTO :EOF

:Uninstall

Sysmon64.exe -u

Sleep 15

GOTO :Install

:EOF

END && EXIT

If you want to auto-deploy Sysmon with these scripts, download Sysmon, create the bat script and sysmonconfig.xml, and place all three in your domain’s sysvol directory on the domain controller which manages the segments of your network you want to monitor. Here’s an example:

Then you can create a GPO with a startup script to run and update Sysmon automatically. Here’s an example:

Sysmonconfig.xml

Here’s three different config versions you can use:

Our sysmonconfig is a specialized version of the SwiftOnSecurity version which is customized to increase visibility in the following areas: file creation, networking, and dll image loading.

APPENDIX B – Logging Resources

Quick Sysmon, PowerShell, and Windows GPO deployment

https://github.com/bobby-tablez/Enable-All-The-Logs

SANS on Sysmon

https://www.sans.org/blog/parsing-sysmon-events-for-ir-indicators/

https://www.sans.org/white-papers/39680/

https://www.sans.org/blog/using-sysinternals-system-monitor-sysmon-in-a-malware-analysis-lab/

SANS on fileless attacks

https://www.giac.org/paper/gcfa/11563/hunting-ghosts-fileless-attacks/150888

Microsoft on Sysmon

https://azure.microsoft.com/en-us/blog/detecting-in-memory-attacks-with-sysmon-and-azure-security-center/

Black Hills Infosec on Sysmon+