Threat hunting pack
- Juan Tomás Alonso Nieto (Deactivated)
This query pack is intended to help to identify cybersecurity threats into those devices which are under Devo Endpoint Agent scope. Currently, it’s only going to cover Windows endpoints, but it will be evolved to cover others.
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.
From now some Windows threat hunting key services and features will be covered.
Threat hunting techniques used here are strongly dependent on system configuration. To avoid false positives queries must be reviewed and tuned to suit each case needs. Please review the following section to inspect how to customize the queries
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.
As noted above, detection pack queries can generate false positives if not configured properly. Thus be sure to check systems configuration and once you are sure that everything is ok, set that as ‘known-secured-config’.
From that point, everything that appears under detections Devo subtag must be considered as suspicious and be reviewed. This does not mean that all registries included under detections comes from cybersecurity threats, it can be also come from new software installed, or new configurations, but it is should 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). But before reaching that point, queries and its results must be reviewed and configured. What one customer could consider as part of well known installed software behavior, another could identify as a high impact cybersecurity threat.
Taking into account the above, 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 don't filter at all, you’ll probably get a lot of results, but from that moment, only new ones will be recorded and shown. First time false positives can be reviewed in that initial execution, if you don’t want to filter queries, and from then each new result returned can be treated as suspicious. Of course, default query execution latency can be also changed to suit your needs.
As it is introduced before, each one of the detections detected by the queries included in the pack is mapped to MITRE ATT&CK framework, providing detailed information about the security issue. This mapping is included into the query through the first fields. For instance, lets have a look on sub-technique T1037.001 (https://attack.mitre.org/techniques/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 (to get more detailed information it’s recommended to familiarize with MITRE ATT&CK structure. Fields severity and severity_level 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 the customers.
System information related with 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 either since they include key data to understand and track the suspicious element.
Finally, the queries include various filtering statements (depending on the case), in this case the query filters by a 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 concrete folder. Customer system administrators see the information ingested in Devo under 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 (or similar ones) 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 parts of the queries that can be modified without missing data are the filtering logic statements.
Deployment procedure
Detections osquery package is intended to be downloaded and installed independently of EA version installed. 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 from its public link:
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 into /home/ folder, please 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.yaml Once the pack file is copied to the deployer folder, you must include it in the inventory file used to deploy the ansible project, as part of the list of packs under deam_packs_enabled variable, for example:
(This snippet of code is just an example, it can differ in your installation, the only important thing is to include detections.yaml under deam_packs_enabled )
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 new pack and its queries will be visible into 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.
First of all, it is important to remark that each company or even each company’s area configures and sets up systems differently. That’s why a fine tuned query that works perfectly in certain environments may generate a huge amount of false positives in another.
Taking into account the above it’s important to understand that scheduled task queries included 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 | |
| Retrieve scheduled tasks that execute script utilities from full access directories | Execution/Persistence/Privilege Scalation | Scheduled Task/job | |
| Retrieve scheduled tasks with path outside \Microsoft\Windows that execute script utilities | Execution/Persistence/Privilege Scalation | Scheduled Task/job |
All the queries included in that pack related to Windows scheduled tasks are generated from the basic following structure:
Which 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 \Microsoft\Windows path as it can be seen in the following screenshot:
Â
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, for example:
Always taking into account that malicious tasks can be also created under legitimate filtered paths to trick sysadmins, since these paths depend on the installed software, and local config of each system these query is not included to avoid false positives, but 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 writable 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 used frequently as tools to perform other malicious activities. It's interesting to identify those scheduled tasks that use it, taking into account that default legitimate system tasks use those utilities too.
The third query included looks for scheduled tasks that perform actions with those tools outside of default path (\Microsoft\Windows):
Windows registry queries
The registry in Windows stores data in binary format, 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 that configuration files determine how the system behaves it is a key point to be exploited by cyberattacks.
There are multiple techniques used by malware and cyberattackers that involve Windows Registry, and its goals can be from achieve persistence to privilege escalation or code execution. In this query pack we have focused in those that can be mapped using MITRE ATT&CK framework to the tactics Persistence(TA0003) and Privilege Escalation(TA0004).
All of these queries extract information from osquery schema table registry, which theoretically provides access to all registry hives, but on the field there are some limitations. All directories, keys and subkeys under the hive HKEY_CURRENT_USER are not queriable 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. This has to be taken into account when the detection query pack is enabled, as we have carried out various tests in different systems with various hardware configurations, but it’s difficult to simulate a production environment system workload and conditions. We suggest you enable the pack excluding those queries, test system performance, and then enable them one by one, monitoring the system to avoid system resources exhaustion.
All the queries included in the pack regarding windows registry try to identify the same behavior patterns, which are modifications of registry keys default value to a custom one or creation of certain registry keys.
A list of the included queries can be found below including its mapping to 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 | 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 Initialization Scripts | Yes | |
| Retrieve values of screensave configuration | Persistence/Privilege Scalation | Event Triggered Execution | 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 | 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 | No | |
| Retrieve values of Winlogon config features | Persistence/Privilege Scalation | Boot or Logon Autostart Execution | Yes |
As was mentioned before. all the queries in their current state consider as a detection everything that differs from Windows default configuration, and must be configured and filtered to avoid false positives or left without filtering, and check the first execution result to identify if all is ok or if there are suspicious results.
Let’s have a look at a couple of the queries executed in a test environment to better understand 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 MITRE ATT&CK related article, netsh.exe (also referred to 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 for extending functionality of the utility. The paths to 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.
As you can see, this is a system tool that loads a set of legitimate DLLs to extend its features, if an attacker changes, or adds, the value of one of those DLLs, the tool would be able to execute a malicious DLL in the system. Since, by default the tool loads a set of DLLs, if the query is not filtered, the first time it is executed it will retrieve a list of results including all of those DLLs:
Please, take into account that results come from a test environment, results in your systems could differ.
If you don't want to filter the queries you could review the execution result and check if al of those dlls are legitimate, and (since query mode is set as incremental) from that moment each new result coming from netsh.exe configuration with changes in that values should be treated as suspicious and reviewed to determine their legitimacy.
Second query is devo_registry_screensave_config_key, its structure can be 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 screensaver is active, it doesn’t require a password to be unlocked and is pointed to a PE it must be reviewed no matter what inactivity timeout it has) it is necessary 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 seen in the picture:
Please, 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, have a list of folders where program shortcuts can be stored, which are needed to start once the OS starts. Generally its path is the following (mainly in 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 storing its information into a single table startup_items, but 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 is executed since it is not filtered. If you don't 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.