Skip to content

Configuring whitelisting functions and understanding how to use them

Jump to bottom
Edoardo Gerosa edited this page Jan 9, 2021 · 7 revisions

Whitelisting overview

Sentinel-ATT&CK comes bundled with a Sysmon whitelisting solution. Out of the box Sysmon generated large amounts of noise and Sentinel-ATT&CK whitelists provide an effective solution to exclude legitimate processes from query results.

Sentinel-ATT&CK's whitelisting solution relies on two components:

1. Whitelist CSV storage files: to store legitimate processes to be excluded from query results

2. Whitelisting functions: that allow Sentinel-ATT&CK workbooks to query CSV storage files. The whitelisting functions are automatically provisioned within the Sysmon threat hunting workbook.

In order for Sentinel-ATT&CK's dashboards and workbooks to function properly both components must be installed.

Installing whitelisting CSV storage files

Note: If you deployed your Sentinel lab using the Terraform script provided in the lab folder you can skip this section and move directly to the next, as all CSV storage files will have already been deployed for you.

Whitelisting CSV storage files are located in the lab/files folder. To install the whitelisting storage folder you must:

  1. Deploy an Azure Storage Account within the Resource Group of your Sentinel instance
  2. Deploy an Azure Storage Container within the freshly deployed Storage Account
  3. Upload all .csv files in the lab/files folder into the deployed Azure Storage Container

Using whitelisting CSV storage files

Once all of the installation steps above have been completed you will be able to use whitelisting files to exclude legitimate processes from Sentinel-ATT&CK queries.

Sentinel-ATT&CK provides 10 whitelists, modelled against Sysmon events, for you to filter legitimate processes. The whitelists are:

  • DNS whitelist - to exclude legitimate Sysmon Event ID 22 activity
  • File create whitelist - to exclude legitimate Sysmon Event ID 9 activity
  • File create whitelist - to exclude legitimate Sysmon Event ID 11 activity
  • Image load whitelist - to exclude legitimate Sysmon Event ID 7 activity
  • Network whitelist - to exclude legitimate Sysmon Event ID 3 activity
  • Pipe whitelist - to exclude legitimate Sysmon Event ID 17 & 18 activity
  • Process access whitelist - to exclude legitimate Sysmon Event ID 10 activity
  • Process create whitelist - to exclude legitimate Sysmon Event ID 1 activity
  • Registry whitelist - to exclude legitimate Sysmon Event ID 13 and 12 activity
  • Remote thread whitelist - to exclude legitimate Sysmon Event ID 8 activity

To whitelist legitimate processes you simply have to fill in the CSV fields as indicated by the included headers. CSV whitelist files can be edited directly within the Azure Blob Storage pane or, better, maintained as offline files to be re-uploaded to relevant Azure Storage blobs.

With the exception of the process create whitelist, you can directly copy-paste legitimate Sysmon activity data from Kusto results tables into the applicable CSV whitelist.

In the process create whitelist data can be directly copy pasted from Kusto result tables into the CSV file with the exception of the process_command_line field. Due to issues in the way Sysmon command line data is returned within Kusto result tables all paths entered under this header must be enclosed within single quotes (') as per the example below:

host,user,process_parent_path,process_path,process_command_line,hash_sha256,reason
,,,,'"C:\Program Files\Microsoft Monitoring Agent\Agent\MonitoringHost.exe" -Embedding',,
,,,,'"C:\windows\system32\cscript.exe" /nologo "MonitorKnowledgeDiscovery.vbs"',,

Failing to enclose path data into single quotes will break Sentinel-ATT&CK queries to the process create whitelist.

Clone this wiki locally