December 27, 2018 / by Cheryl Dsa / In siem , security-analytics /

Application Whitelisting - What is it and how it works

The concept of a blacklist is one we’re all familiar with. In the field of IT security, any list of discrete entities deemed to be suspicious or malicious — thereby warranting blocking in some way — can be called a blacklist. Creating a blacklist of malicious object hashes, virus signatures, and so on was once very simple and convenient. However, with the amount of malware and other attacks in the wild constantly on the rise, keeping a signature-based blacklist up to date is nearly impossible.

Enter the concept of a whitelist: a list of entities that are safe, and thus granted some kind of authorization. Rather than listing out all the potentially malicious entities that you want to block, you can create a shorter, much simpler list of just the applications and processes that you want to permit on your system. This process is known as application whitelisting.

Defining application whitelisting

Simply put, application whitelisting is the process of creating a list of applications and processes that are authorized to be present or active on a host. It is a practical and realistic approach to guarantee that only safe and authorized applications will be allowed to run on your system.

Application whitelisting is effective in preventing the installation and execution of any application or process that is not explicitly authorized for use on a particular host. It reduces the threat posed by various categories of malicious object, including malware and other unauthorized software, making it one of the most powerful SIEM Usecases.

How does it work?

The application whitelisting process is quite simple. It comprises the following steps:

  1. Scan a clean system’s folders and drives to detect the applications and processes you wish to allow.
  2. The executable files detected in the scan will be added to a whitelist.
  3. If necessary, add or update specific files and applications in the list after it has been generated.
  4. Enforce the whitelist, putting the system into a protected state. Any application that attempts to run on your system will first be compared against the whitelist. Applications will be allowed to run only if a match is found in the list.

Each executable in the whitelist is uniquely identified, typically by file name, file size, file path and hash. Hashing may be used as a secondary measure to ensure a program is actually what it appears to be: any change to a file will completely change the file’s hash. This prevents programs designed to mimic approved programs from being executed.

Application whitelisting at DNIF

Here’s how we do it in DNIF. A whitelist can be built into the Windows operating system with the help of information from a third-party vendor. The simplest form of whitelisting allows a system administrator to specify file attributes associated with whitelisted applications, such as file name, path, size and hash. To detect malicious processes, DNIF gets hashes of applications on the system using Microsoft’s Sysmon and validates them against hashes from VirusTotal reports.

Download a complete list of five easy to implement automation usecases to kick start your security program.

Traditional blacklists are useless against malware that takes advantage of a zero-day vulnerability — if a particular attack has never been observed, it cannot be blacklisted. However, application whitelisting can stop such an attack. All non-whitelisted applications are validated against a lookup and blocked if found to be malicious. To detect such an attack, DNIF makes use of Sysmon’s event ID 1, which logs new process creations.

To get started, please make sure you have Virustotal plugin integrated in DNIF, for steps please refer -

Virustotal Integration with DNIF

The following query calculates unique hashes for every unique process and checks for their presence in the whitelisted store. Application hashes that are not present in the whitelist are then validated against a lookup with VirusTotal. If the application is not malicious, it is then added to a local store.

_fetch * from event where $Duration=1h AND $LogName=WINDOWS-SYSMON AND $EventID=1 group count_unique $App, $HashMD5 limit 1000
>>_checkif lookup windows_hashes join $App = $App str_compare $HashMD5 eq $HashMD5 exclude
>>_limit 4
>>_lookup virustotal get_filehash_report $HashMD5
>>_checkif int_compare $VTResponseCode = 1 include
>>_checkif int_compare $VTPositives > 1 exclude
>>_store in_disk windows_hashes stack_append

cron schedule: 0,30 * * * *

The same process is followed in the following query, with the exception that a module will be raised if an application is found to be malicious by the VirusTotal lookup.

_fetch * from event where $Duration=1h AND $LogName=WINDOWS-SYSMON AND $EventID=1 group count_unique $App, $DevSrcIP limit 1000
>>_checkif lookup windows_hashes join $App = $App str_compare $HashMD5 eq $HashMD5 exclude
>>_limit 4
>>_lookup virustotal get_filehash_report $HashMD5
>>_checkif int_compare $VTResponseCode = 1 include
>>_checkif int_compare $VTPositives > 1 exclude
>>_store in_disk windows_hashes stack_append
>>_raise module mswin2k8_threat_hunting malicious_application_started $DevSrcIP 4 12h

cron schedule: 2,32 * * * *

The following query retrieves the hashes of unresolved applications and checks them against a lookup with VirusTotal. If information on a particular hash is found, it is updated in the local store.

>>_retrieve windows_hashes
>>_checkif key_exists $VTScanID exclude
>>_limit 4
>>_lookup virustotal get_filehash_report $HashMD5
>>_store in_disk windows_hashes key_replace $HashMD5

cron Schedule: 4,34 * * * *

Here’s a complete demonstration of application whitelisting:


five effective siem usecases