Threat hunting pack
- Juan Tomás Alonso Nieto (Deactivated)
Analytics
This query pack is intended to help identify cybersecurity threats on devices which are under the scope of the Devo Endpoint Agent. At the moment it only covers Windows endpoints but there are plans to expand it to other endpoints in the future.
Its data structure and background is inspired by MITRE ATT&CK matrix, which is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community.
Threat hunting techniques used here are strongly dependent on system configuration. To avoid false positives, queries must be reviewed and tuned to suit the needs of each case.
General Considerations
Data structure created in Devo under box.devo_ea.detections tagging is intended to be filled only by what is considered a detection, and that is why queries need to be tuned to avoid false positives.
Be sure to check your system's configuration, and once everything is ready, set that as "known-secured-config".
From that point, everything that appears under the detections Devo subtag must be considered as suspicious and be reviewed. This does not mean that all registries included under detections come from cybersecurity threats, as it can also come from newly-installed software or new configurations. However, we recommend that it be reviewed and classified as not dangerous (and then included in your filtering logic if needed) or dangerous (and take the necessary actions to solve it).
Before doing this, queries and their results must be reviewed and configured. What one might consider part of a well-known installed software behavior, others might consider a high-impact cybersecurity threat.
Taking into account the above, the initial configuration of detection pack queries is intended to be incremental. Each query, by default, is executed once per hour comparing the values obtained in the last execution, and displaying only those that are new (differential results). This means that if you do not filter at all, you are likely to get a lot of results. However, from that moment on, only new ones are recorded and shown. First time false positives can be reviewed in that initial execution, if you do not want to filter queries, and from then on each new result returned can be treated as suspicious. Default query execution latency can be also changed to suit your needs.
As previously mentioned above, each one of the detections detected by the queries included in the pack is mapped to the MITRE ATT&CK framework, providing detailed information about the security issue. This mapping is included in the query in the first few fields. Let's have a look at sub-technique T1037.001. The query to detect this sub-technique is the following:
SELECT 'MITTRE ATT&CK' AS framework,
'v9' AS framework_version,
'TA0003/TA0004' AS tactic_id,
'Persistence/Privilege Scalation' AS tactic_name,
'T1037' AS technique_id,
'Boot or Logon Initialization Scripts' AS technique_name,
'T1037.001' AS subtechnique_id,
'Logon Script' AS subtechnique_name,
'M1024' AS mitigation_id,
'Restrict Registry Permissions' AS mitigation,
'3' AS severity_level,
'High' AS severity,
name AS name,
key AS path,
data AS details,
'detections' AS __devoSubTag
FROM registry
WHERE key LIKE 'HKEY_USERS\%%\Environment'
AND name = 'UserInitMprLogonScript'The MITRE ATT&CK mapping fields are those included from framework to mitigation. The severity and severity_level fields are filled with an incremental value according the criticality of the detection, having severity as string value (low/medium/high) and severity_level as numeric (1/2/3). The values included in these fields are fixed and are not intended to be changed by customers.
System information relatedto the detection is included in the next three fields (name, path, details), those values are not filled in the same way in all the queries, but generally include information about the name of the element detected, its path, and its value or data included to be considered as detection. It is preferable to not modify those values as they include key data to understand and track the suspicious element.
Finally, the queries include various filtering statements, in this case the query filters by certain registry keys path and name. These are the statements that can be modified and tuned to suit each customer's needs.
For example, with the query shown before, let’s suppose that is included in an EA customer environment and it retrieves a path to a script stored in a certain folder. Customer system administrators see the information ingested in Devo under the detections subtag, and when they inspect the script they realize that is part of their well-known security suite included on all their systems. Since they do not want that information to be ingested again, they add a new filtering statement just after the name of the registry key:
.......
FROM registry
WHERE key LIKE 'HKEY_USERS\%%\Environment'
AND name = 'UserInitMprLogonScript'
AND data != '\Temp\XXXXX\%well-known-script-common-name%.ps1'
The only part of the query that can be modified to customize it without missing data are the filtering logic statements.
Deployment procedure
Detections osquery package is intended to be downloaded and installed independently of EA version. The following steps illustrate how to download, include the .yaml file in deployer configuration, and deploy the pack to be included in fleet instance.
First of all download the file:
Once the file is downloaded, upload it to your manager instance and copy it into the right folder (in the following example the .yamlfile is in /var/tmp and the deployer folder in the /home/ folder. Change the command to suit your needs)
cp /var/tmp/detections.yaml /home/devo-ea-deployer/playbooks/roles/deam-packs/files/optional-devo-packs/detections.yamlOnce the pack file is copied to the deployer folder, it is necessary to include it in the inventory file used to deploy the ansible project, as part of the list of packs under deam_packs_enabled variable:
Once it is included in the inventory file, the ansible playbook can be launched to install the new pack in the EA Manager:
If everything goes OK, a new pack and its queries will be visible in the EA Manager, and it will be propagated to agents.
Windows scheduled tasks queries
The goal of these new packs is to provide tools to Devo Endpoint Agent users to help them identify security issues.
It is important to remark that each company, or even each company’s area, configures and sets up systems differently. That is why a finely-tuned query that works perfectly in certain environments may generate a huge amount of false positives in another.
With this in mind, it is important to understand that any scheduled task queries must be customized to meet your needs.
Scheduled tasks are a key feature used by cyberattackers or malware to accomplish what is called persistence. Once a cyber attack is performed and access to the system is gained, next step is to ensure access is going to be maintained, for example, if the system is rebooted (most simple case). Scheduled tasks are also used as a technique of command execution and privilege escalation.
The attackers take advantage of the amount of default and legitimate scheduled tasks a Microsoft system includes, and that’s where company sysadmins and security teams knowledge is necessary, to determine which are legitimate system tasks and which are not.
In ATT&CK matrix terms non-legitimate usage of scheduled tasks is matched as technique T1053 Scheduled Task/Job and is included in tactics Execution, Persistence and Privilege Escalation. More detailed information about the scheduled tasks related queries can be found below:
Query name | Query description | Tactic name | Technique name | MITRE ATT&CK rational |
|---|---|---|---|---|
| Retrieve scheduled tasks that execute files from full access directories | Execution/Persistence/Privilege Scalation | Scheduled task/job | Scheduled Task/Job: Scheduled Task, Sub-technique T1053.005 - Enterprise | MITRE ATT&CK® |
| Retrieve scheduled tasks that execute script utilities from full access directories | Execution/Persistence/Privilege Scalation | Scheduled task/job | Scheduled Task/Job: Scheduled Task, Sub-technique T1053.005 - Enterprise | MITRE ATT&CK® |
| Retrieve scheduled tasks with path outside \Microsoft\Windows that execute script utilities | Execution/Persistence/Privilege Scalation | Scheduled task/job | Scheduled Task/Job: Scheduled Task, Sub-technique T1053.005 - Enterprise | MITRE ATT&CK® |
All the queries included in the pack related to Windows scheduled tasks are generated from the basic following structure:
This returns all the scheduled tasks of the system matched with ATT&CK framework.
To better understand how osquery extracts data from scheduled tasks, it is important to know how these tasks are organized.
Windows manages scheduled tasks using paths. By default all system tasks are under the \Microsoft\Windows path as shown in the following image:
Other software manufacturers generate other paths or can include it under the \Microsoft\Windows path.
Malware and attackers usually create scheduled tasks with uncommon paths, filtering all trusted paths could be helpful to identify unusual tasks:
Keep in mind that malicious tasks can also be created under legitimate filtered paths to trick sysadmins. As these paths depend on the installed software and local config of each system, these queries are not included to avoid false positives, but it is a good example.
The first query of the pack tries to identify another common malicious behavior; which is to run scheduled tasks from temporal directories or locations that can be written by any user. This can be detected including a list of those locations and folders:
Another filtering layer (second query) can be added, looking for scripting utilities launched from those locations:
Scripting utilities are frequently used as tools to perform other malicious activities. It is interesting to identify the scheduled tasks that use them, taking into account that default legitimate system tasks use those utilities too.
The third query looks for scheduled tasks that perform actions with those tools outside of the default path (\Microsoft\Windows):
Windows registry queries
The registry in Windows stores data in binary form, keeping the configuration data for the machine and its users in separate files. This allows the system and its applications to load global and individual configurations upon startup and login. Since the values stored in the configuration files determine how the system behaves, it is a key point to be exploited by cyber attacks.
There are multiple techniques used by malware and cyber attackers that involve Windows Registry, and their aims range from achieving persistence to privilege escalation or code execution. In this query pack we have focused on those that can be mapped using the MITRE ATT&CK framework to the tactics Persistence(TA0003) and Privilege Escalation(TA0004).
All of these queries extract information from the osquery schema table registry, which theoretically provides access to all registry hives, but there are some limitations in the field. All directories, keys, and subkeys under the hive HKEY_CURRENT_USER are not queryable by osqueryd, and to access its information, queries must be modified to query HKEY_USER hive instead. Since HKEY_USER hive is divided by user ID directories, it must be queried recursively. These facts must to be taken into account when detection the query pack is enabled. We have carried out various tests in different systems with various hardware configurations, but it is difficult to simulate a production environment system workload and condition. We suggest you enable the pack excluding those queries, test the system performance, and then enable them one-by-one monitoring, the system to avoid system resource exhaustion.
All the queries included in the pack regarding windows registry try to identify the same behavior patterns, which are modifications of the registry keys' default value to that of a custom one, or the creation of certain registry keys.
A list of the included queries can be found below, including its mapping to the MITTRE ATT&CK framework and if they search recursively under a registry hive:
Query name | Query description | Tactic name | Technique name | MITRE ATT&CK rational | Recursive search in hive (potential performance issues) |
|---|---|---|---|---|---|
| Retrieve value of AppInit_DLLs registry key | Persistence/Privilege Scalation | Event Triggered Execution | Event Triggered Execution: AppInit DLLs, Sub-technique T1546.010 - Enterprise | MITRE ATT&CK® | No |
| Retrieve value of Authentication Packages registry key when its value is different from default | Persistence/Privilege Scalation | Boot or Logon Autostart Execution | No | |
| Retrieve value of environment items that are loaded when a user logs on | Persistence/Privilege Scalation | Boot or Logon Autostart Execution | Yes | |
| Retrieve values of screensave configuration | Persistence/Privilege Scalation | Event Triggered Execution | Event Triggered Execution: Screensaver, Sub-technique T1546.002 - Enterprise | MITRE ATT&CK® | Yes |
| Retrieve values of services and programs executed when certain user logs on | Persistence/Privilege Scalation | Boot or Logon Autostart Execution | Yes | |
| Retrieve values of services and programs executed when all users log on | Persistence/Privilege Scalation | Boot or Logon Autostart Execution | No | |
| Retrieve values of DLLs loaded by netsh | Persistence/Privilege Scalation | Event Triggered Execution | Event Triggered Execution: Netsh Helper DLL, Sub-technique T1546.007 - Enterprise | MITRE ATT&CK® | No |
| Retrieve values of currently installed shims and custom databases associated | Persistence/Privilege Scalation | Event Triggered Execution | No | |
| Retrieve values of Image File Execution Options (IFEO) debuggers | Persistence/Privilege Scalation | Event Triggered Execution | No | |
| Retrieve values of AppCertDLLs loaded | Persistence/Privilege Scalation | Event Triggered Execution | Event Triggered Execution: AppCert DLLs, Sub-technique T1546.009 - Enterprise | MITRE ATT&CK® | No |
| Retrieve values of Winlogon config features | Persistence/Privilege Scalation | Boot or Logon Autostart Execution | Yes |
Let’s have a look at a couple of the queries executed in a test environment to understand better its behavior.
To begin with both of them include general info about MITRE ATT&CK mapping, having the details of the detection stored into path, name and details fields.
The query devo_registry_netsh_dlls_key implementation is the following:
As is detailed in the MITRE ATT&CK article, netsh.exe (also known as Netshell) is a command-line scripting utility used to interact with the network configuration of a system. It contains functionality to add helper DLLs to extend functionality of the utility. The paths to the registered netsh.exe helper DLLs are entered into the Windows Registry at HKLM\SOFTWARE\Microsoft\Netsh.
Adversaries can use netsh.exe helper DLLs to trigger execution of arbitrary code in a persistent manner. This execution would take place anytime netsh.exe is executed, which could happen automatically with another persistence technique, or if other software is present on the system that executes netsh.exe as part of its normal functionality.
It is a system tool that loads a set of legitimate DLLs to extend its features. If an attacker changes the value of one of those DLLs, they could execute a malicious DLL in the system. By default the tool loads a set of DLLs, so if the query is not filtered then the first time it is executed it will retrieve a list of results including all of those DLLs:
Take into account that results come from a test environment, results in your systems could differ.
If you do not want to filter the queries you could review the execution result and check if all of those DLLs are legitimate, and from that moment each new result coming from netsh.exe configuration with changes in values should be treated as suspicious and reviewed to determine its legitimacy.
The second query is devo_registry_screensave_config_key, its structure is shown below:
From its MITRE ATT&CK rational, screensavers are programs that execute after a configurable time of user inactivity and consist of Portable Executable (PE) files with a .scr file extension. The Windows screensaver application scrnsave.scr is located in C:\Windows\System32\, and C:\Windows\sysWOW64\ on 64-bit Windows systems, along with screensavers included with base Windows installations.
The following screensaver settings are stored in the Registry (HKCU\Control Panel\Desktop\) and could be manipulated to achieve persistence:
SCRNSAVE.exe- set to malicious PE pathScreenSaveActive- set to '1' to enable the screensaverScreenSaverIsSecure- set to '0' to not require a password to unlockScreenSaveTimeout- sets user inactivity timeout before screensaver is executed
Adversaries can use screensaver settings to maintain persistence by setting the screensaver to run malware after a certain timeframe of user inactivity.
Since we need to extract at least the first three elements of the list (we consider that if screen save is active, not requires password to unlock and is pointed to a PE it must be reviewed no matter what inactivity timeout it has) it is needed that query structure, filtering by those three values and grouping by key to ensure the three are present. Since ScreenSaveActive = 1 and ScreenSaverIsSecure = 0 are fixed by the query filtering , only the path (data field of registry osquery table) of SCRNSAVE.exe is included in details .
This query will only show a single result if something is detected like it can be seen in the picture:
Take into account that results come from a test environment, results in your systems could differ.
Windows startup items queries
Like registry and scheduled tasks, startup items are a native os feature likely to be exploited to achieve persistence or elevate privileges. Windows, by default, has a list of folders where program shortcuts that are needed to start once the os starts can be stored. Generally its paths are the following (mainly in the latest Windows versions):
For all users in the system:
For each user:
All executable files, shortcuts to them or scripts included in that files will be run with system startup. It is understandable that attackers want to exploit these kind of features.
Osquery manages startup items by storing its information into a single startup_items table. It also includes information about other startup features coming from registry keys. Since that case is covered in registry detections queries, those results are filtered in order to avoid duplicated information. desktop.ini startup item is also filtered. It is a file created to store information about the configuration of File Explorer folders in newer versions of Windows. Regarding ATT&CK mapping, startup item exploitation is classified as Persistence/Privilege Escalation tactic having technique Boot or Logon Autostart Execution.
Startup items related queries can be found below:
Query name | Query description | Tactic name | Technique name | MITRE ATT&CK rational |
|---|---|---|---|---|
| Retrieve values of startup items not loaded from registry | Persistence/Privilege Scalation | Boot or Logon Autostart Execution |
That query has the following structure:
As in previous cases, this query is going to return all the items included in the directories listed before the first time it is executed since it is not filtered. If you do not want to have those first results stored in Devo, including false positives, you must tune the query including filters for users startup folder, or excluding certain apps, for example.