# Analytics
## Detection Analytic Ascendency Model
**Gartner's Analytic Ascendency Model** is a data and analytics maturity model that was introduced in 2012. The initial purpose of this model is to help organizations determine their data and analytics maturity level. The model identifies four types of analytics:
* **Descriptive Analytics :** What happened ?
* What telemetry was generated ?
* What are the changes observed on the targeted host ?
* **Diagnostic Analytics :** Why it happened ?
* What enabled the attacker to perform such an attack ?
* **Predictive Analytics :** What could change ?
* What the attacker can change to evade this detection ?
* **Prescriptive Analytics :** What should be done ?
* What can we do to stop it ?
Bellow I tried to adapt this model in order to create a sort of framework to illustrate common steps taken by a detection engineer for analytics design. Feel free to not take this as it is since my goal is only to create common ground for team members in order to measure the resiliency and quality of the produced detections.
You can notice how are the first two steps are more related to the **logic** behind the detection analytic and the two last ones can be used to refine analytic quality to achieve a good **resilience** level. in the following section I will try to define how can we approach both of these concepts and finish with a use case study to illustrate this adaptation for detection analytics design.
## Analytic Logic
Many detection engineers out there wrote great blogs about their approach of designing detection logic like [@SBousseaden](https://twitter.com/SBousseaden) blog post [**How to Design Detection Logic - Part 1**](https://blog.menasec.net/2020/11/how-to-design-detection-logic-part-1.html) or [@jaredcatkinson](https://twitter.com/jaredcatkinson)'s [**Capability Abstraction**](https://posts.specterops.io/capability-abstraction-fbeaeeb26384) article. However, both start from the same idea that is detection analytics demand a deep understanding of the attack technique, whether you want to extract primitives or capabilities.
There are three main approaches to detection logic design:
### **Know Normal; Find Evil Approach (KNFE) :**
The study of what is normal. This blog on [**How to Design Abnormal Child Processes Rules Without Telemetry**](https://blog.menasec.net/2021/01/how-to-design-abnormal-child-processes.html) by [@SBousseaden](https://twitter.com/SBousseaden) is a great use case to understand this approach where the author built a **`WerFault.exe`** abnormal behavior detection from studying usual **imported modules**, **process creation related APIs** and normal **parent-child process relationships**. This approach can also be based on your own environment baselines like :
* **Software and application control baselines.**
* **Assets baselines.**
* **Normal process behavior.**
* **Normal network protocol behavior.**
### Follow the Breadcrumbs Approach (FBC) :
As the first approach can be time consuming. FBC is an observational approach where we study the attack technique's fingerprints by observing what relevant telemetry was left behind or generated during the technique execution. ***A deep knowledge of what capabilities the technique is using is necessary for good detection results***.
### Hybrid:
A combination of both.
## Analytic Resilience
The worst kind of false negatives are the ones you have already built detections for. Your detection analytic can be challenged and bypassed by mutational aspects of some of the techniques they will face, and attacker knowledge of how the environment behave under some circumstances like obfuscation for instance would push you to consider reviewing the resilience of your analytics. Think of it as the vaccine efficacy against several mutations of the same virus. The followings are some aspects you can take in consideration while evaluating analytic resilience.
### Technique Volatility : What the attacker can control
Attackers have a degree of control over the techniques they perform, depending on the technique, they can be able to change the command line arguments through obfuscation, rename binaries they will use or bypass analytics using time based correlation evasion techniques.
#### Renaming Binaries
Attackers can rename the executables they're using in order to evade hardcoded detection based on binaries names. Here event traceability, discussed in the previous dimension "**Execution**", can help to identify useful telemetry like **Sysmon EID 1** that provides a field with **`Original File Name`**. Also, try to use arguments as much as possible, this is not to stop attackers but to increase the cost of required skillset since tools are easily renamed but it is more complex and time consuming to recompile them to change their options.
#### Command Line Obfuscation
Command Line obfuscation can be a nightmare while writing detection analytics queries. The problem obviously is the same command can be written in different expressions and still be valid. The blog post [**Windows Command-Line Obfuscation**](https://www.wietzebeukema.nl/blog/windows-command-line-obfuscation) by [@Wietze](https://www.twitter.com/wietze) will give you a really detailed overview of this challenge.
#### Time Based Correlation Bypass
In most SIEM I've seen, rules are almost executed every **5 or 10 minutes** all the time. A crafty attacker that controls the flow of execution can bypass the entire logic behind a detection by spreading the generation of event logs in a larger timeline. A threat hunting process or historical correlation can fill the gaps and detect this approach.
#### Signature
The modularity of an attacker toolset can be very effective in bypassing your detection analytics, so before you go and use some telemetry properties like an Access Mask, a Logon Type, a Service Type...etc make sure that the attacker cannot change that artifact. Again, remember that detection mission is not to stop the attacker (it is only the beginning of a whole process) but to increase the cost and effort they have to invest in order to go undetected.
### Event Causality : What the attacker cannot control
From an attacker point of view if you can't catch **cause** then look for its potential **effects**. For example a tool like [**DoUCMe**](https://github.com/Ben0xA/DoUCMe) by [@Ben0xA](https://twitter.com/Ben0xA) "*leverages the **NetUserAdd Win32 API** to create a new computer account. This is done by setting the **usri1\_priv** of the **USER\_INFO\_1** type to **0x1000**.
**The primary goal is to avoid the normal detection of new user created events (4720).***"
Event causality can be used here since every computer or user account creation is always proceeded by **A user account was enabled** (**4722**), **A computer account was changed** (**4742**) and **An attempt was made to reset an accounts password** (**4724**). So instead of focusing your detection on the cause which will generate the event **A computer account was created** (**4741**) or **A user account was created** (**4720**) you can focus on those three events instead.
### Event Decisiveness
Most of the times a detection relies on several event logs from one or multiple data sources, but each event can have different decisiveness over the confidence of the detection logic. Event decisiveness can be used to differentiate logic building blocks into separate analytics, meaning that, for some detections, some events are so powerful that they can be an analytic on their own. We will see an example in **predictive analytic** section of the use case bellow.
## Use Case : Detecting Remote Credentials Dumping via comsvcs.dll
### Lab environment:
* Winlogbeat Agent and Sysmon for endpoint telemetry
* Zeek for network telemetry.
* Elastic Stack for centralized logging and correlations
* Tool : **Lsassy 3.0.0 by** [**@HackAndDo**](https://twitter.com/HackAndDo)
* Supported dumping methods :
* **comsvcs**
* **procdump**
* **dumpert**
* **dumpertdll**
* Supported execution methods :
* **Remote Service Creation (smb.py)**
* **Remote Scheduled Task Creation (task.py)**
* **Remote Command Execution via WMI (wmi.py)**
* Key Features:
* **Dumping at scale by targeting multiple hosts at once.**
* **On-Host parsing capability without the need to download the dump and parse it offline.**
* **Stealthy implementations to evade detections.**
* **Highly customizable and modular to add custom dumping techniques.**
## Descriptive Analytic : What happened ?
In this demo we used **`comsvcs.dll`** dumping technique with **SMB** execution method. Later, we will demonstrate a stealthier approach with the same tool. However, upon execution, here are our first observations :
* A service was created with a random name
* The service was configured with a one-liner service file name to find and dump LSASS process memory using a **`LOLBin`** technique based on**`COMSVCS.DLL`**.
* The service is configured to start on demand when the **`StartService`** function is called
{% hint style="warning" %}
## Descriptive Analytic:
**Event ID 4697 / 7045 :**
Service installed
* Service File Name : **`*comsvcs.dll*`**
**Event ID 1**:
Process created
* Process Name : **`cmd.exe`**
* Process Parent Name : **`services.exe`**
* Process Command Line arguments : **`MiniDump`**, **`full`**, **`rundll32.exe`**, **`*comsvcs.dll`**
{% endhint %}
{% hint style="danger" %}
Logic is valid. However, detection resilience is very low
{% endhint %}
## Diagnostic Analytic : Why it happened
The WHY here is not about an attacker's intent but about what enabled the attacker to do this. Here are some key points to consider.
* The service control manager (SCM) is an RPC server that enables service configuration and control of service programs. It was leveraged by the SMB.py exec module of lsassy to remotely create a service on the targeted machine.
* SCM supports remote procedure calls over both Transmission Control Protocol (RPC/TCP) and named pipes (RPC/NP).
* The server interface is identified by **`UUID 367ABB81-9844-35F1-AD32-98F038001003`** and uses RPC endpoint "**`\PIPE\svcctl`**". According to Microsoft documentation, the server **MUST** use RPC over SMB, **ncacn\_np** or RPC over TCP, or **ncacn\_ip\_tcp** as the RPC protocol sequence to the RPC implementation. \[See references bellow]
* After binding to the server interface the tool uses **`OpenSCManagerW`** function that establishes a connection to the service control manager on the specified computer and opens the specified service control manager database.
```cpp
SC_HANDLE OpenSCManagerW(
// The name of the target computer
LPCWSTR lpMachineName,
// The name of the service control manager database. This parameter should be set to SERVICES_ACTIVE_DATABASE. Fixed to registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services at system boot.
LPCWSTR lpDatabaseName,
// The desired access to the service control manager.
DWORD dwDesiredAccess
);
```
* Then it creates a service using **`CreateServiceW`** function
```cpp
SC_HANDLE CreateServiceW(
SC_HANDLE hSCManager,
LPCWSTR lpServiceName,
LPCWSTR lpDisplayName,
DWORD dwDesiredAccess,
DWORD dwServiceType,
DWORD dwStartType,
DWORD dwErrorControl,
LPCWSTR lpBinaryPathName,
LPCWSTR lpLoadOrderGroup,
LPDWORD lpdwTagId,
LPCWSTR lpDependencies,
LPCWSTR lpServiceStartName,
LPCWSTR lpPassword
);
```
* **`comsvcs.dll`** exports a function called `MiniDumpW` which can be used by rundll32 to dump process memory.
* **`comsvcs.dll`** accepts three parameters but the first two are ignored and the third one contains three parts which are the **target process ID**, the **dump file location** and the option **`full`**.
* The **`MiniDump`** function requires a target process ID. Process discovery technique is expected. In this case **`tasklist.exe`** is used to get **LSASS** process ID.
* The **`MiniDump`** function call can also be achieved by function reference number **`#24`**.
* The execution of this method requires **`rundll32.exe`** to request a handle to **`LSASS`**. An **`EID 10`** will be generated with **`comsvcs.dll`** in Call Trace field.
After going through diagnostic analysis more telemetry seems to be relevant to this attack technique. Bellow an updated list of observed events :
{% hint style="info" %}
## Diagnostic Analytic:
**Event ID 5145 :**
A network share object was checked to see whether client can be granted desired access
* Relative Target Name : **`svcctl`**
* Share Name : **`\*\IPC$`**
**Zeek :**
DCE-RPC log file
* DCE-RPC Operation: **`CreateServiceW`** OR **`CreateServiceA`**
* DCERPC Endpoint: **`svcctl`**
**Event ID 12 :**
Registry object create and delete
* Process Name : **`services.exe`**
* Target Object : **`HKLM\System\CurrentControlSet\Services\*`**
**Event ID 13:**
Registry value set
* Process Name : **`services.exe`**
* Image Path: **`HKLM\System\CurrentControlSet\Services\*\ImagePath`**
* Details: **`*comsvcs.dll*`**
**Event ID 7045 / 4697 :**
Service installed
* Service File Name : **`*comsvcs.dll*`**
**Event ID 1 :**
Process created
* Process Name: **`tasklist.exe`**
* Process Command Line Arguments : **`tasklist`**, **`/fi`**, **`Imagename eq lsass`**
**Event ID 1 :**
Process created
* Process Name : **`rundll32.exe`**
* Process Command Line Arguments : (**`MiniDump`** OR **`#24`**) AND **`full`** AND **`*comsvcs.dll`**
**Event ID 10 :**
Process Access
* Source Image : **`*rundll32.exe`**
* Target Image : **`*lsass.exe`**
* Call Trace : **`*comsvcs.dll*`**
**Event ID 4656 :**
A handle to an object was requested
* Process Name : **`*rundll32.exe`**
* Object Name : **`*lsass.exe`**
{% endhint %}
## Predictive Analytic : What could change ?
In predictive analysis we reach the phase where we will be working on analytic resilience. So the next step is to know what the attacker can change in order to evade generating this telemetry. Bellow, I am stating a few but not all possible changes that can be done by the tool **LSASSY** since my goal is not to detect the tool but to understand the underlying capabilities:
1. The attacker in this use case can change the execution method by not creating a **new service** and only **modifying an already existing one**, this will automatically evade detections based on EIDs **7045** and **4697**.
2. The attacker can also **copy** and **rename** the DLL **`comsvcs.dll`** to evade hardcoded string-based command-line detections.
3. The attacker can also adopt the execution of obfuscated and encoded command lines through **`cmd.exe`** or **`powershell.exe`**.
{% hint style="info" %}
All these capabilities will be incorporated in the next major release of the tool
{% endhint %}
## Prescriptive Analytic : What should be done ?
Now that we know some potential mutational properties that the attacker might change we will refine the diagnostic analytic telemetry in order to use ones that will hold up and build a resilient detection analytic.
* Modifying an existing service will result in using **`QueryServiceConfig`** to query the configuration of targeted service the attacker wants to change followed by **`ChangeServiceConfig`** function to apply that change instead of **`CreateService`**. For detection opportunities we can rely on **EID 5145** but Zeek's **`DCE-RPC`** event log has high **Event Decisiveness** and **Traceability** since it provides the exact **endpoint operation** and not just the accessed RPC endpoint **`svcctl`**.
* Event traceability analysis of EID **7045** and **4697** against EID **12** and **13** would eliminate the usage of service creation Windows events logs. The modification or creation of a service configuration would results directly in the **SCM database** registry **`ImagePath`** modification under **`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[`*****`RANDOM`*****`]\ImagePath`**. So we can rely on **EID 13** for this matter.
* In order to copy the **`comsvcs.dll`** file and rename it the attacker needs to reach it first. So an **EID 5145** will be generated in this case with **`comsvcs.dll`** in **`Relative Target Name`** field. This event is highly decisive since it is pretty rare to observe such behavior therefore it can be a detection analytic on its own.
* The attacker can also rely on obfuscation techniques or encoding their command lines. The success of catching malicious obfuscated command can be achieved through your **SIEM/EDR** abilities in **parsing command arguments**, **case-sensitivity** search and recording **de-obfuscated commands**. In this particular technique I will be relying on process access telemetry as an alternative since it is a less risky and much decisive artifact than command-line execution.
* Again in this case we can use two available events, **Sysmon's EID 10** and **Windows event log EID 4656**. An event traceability evaluation would go with **EID 10** in this case because of its its additional **`Call Trace`** field richness and the **`source process GUID`** that can be used for correlation purposes (In my case Elastic Security uses this field to create process trees visualizations). **`rundll32.exe`** accessing **`lsass.exe`** alone is a rare behavior. However, you can increase the precision of your analytic by looking for **`comsvcs.dll`** in **`Call Trace`** or any another **`dll`** from a location other than **`C:\Windows\System32\`**.
{% hint style="success" %}
## Prescriptive Analytic :
**Event ID 5145 :**
A network share object was checked to see whether client can be granted desired access
* Relative Target Name : **`Windows\System32\comsvcs.dll`**
* Share Name : **`\\*\C$`**
**Zeek :**
DCE-RPC log file
* DCE-RPC Operation: **`CreateService*`** OR**`ChangeServiceConfig*`**
* DCERPC Endpoint: **`svcctl`**
**Event ID 5145 :**
A network share object was checked to see whether client can be granted desired access
* Relative Target Name : **`svcctl`**
* Share Name : **`\*\IPC$`**
**Event ID 13:**
Registry value set
* Process Name : **`services.exe`**
* Image Path: **`HKLM\System\CurrentControlSet\Services\*\ImagePath`**
**Event ID 10 :**
Process Access
* Source Image : **`*rundll32.exe`**
* Target Image : **`*lsass.exe`**
{% endhint %}
Bellow is a correlation example of different logic building blocks after adopting **Gartner's Analytics Ascendency Model** to our detection engineering for a resilient detection output. Remember to increase the reliability of your detection, an event visibility evaluation is important. Also to increase the efficiency of your SOC detection capabilities, operationalizing your detection analytics relies on continuous tuning and actionable metrics measurement.
{% hint style="warning" %}
Several other execution methods like Scheduled tasks and WMI can be used with this technique but for brevity I won't be including these options. However similar approach can be used for this matter.
{% endhint %}
## Closing thought
Detection is not enough. Why? because an attacker can go for your telemetry and evade it or stop it from even being generated at the first place. **Proactive**, **preventive** and **deceptive** approaches also should be considered for better coverage.
## References:
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}