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.
Detection Analytic Ascendency Model Adaptation
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 blog post How to Design Detection Logic - Part 1 or @jaredcatkinson's Capability Abstraction 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 by @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 by @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 by @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​
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 onCOMSVCS.DLL.
The service is configured to start on demand when the StartService function is called
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
Logic is valid. However, detection resilience is very low
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]
Lsassy smb.py code snippet
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.
1
SC_HANDLE OpenSCManagerW(
2
// The name of the target computer
3
LPCWSTR lpMachineName,   
4
​
5
// 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.
6
LPCWSTR lpDatabaseName,
7
​
8
// The desired access to the service control manager.
9
DWORD dwDesiredAccess
10
​
11
);
Copied!
Then it creates a service using CreateServiceW function
1
SC_HANDLE CreateServiceW(
2
  SC_HANDLE hSCManager,
3
  LPCWSTR   lpServiceName,
4
  LPCWSTR   lpDisplayName,
5
  DWORD     dwDesiredAccess,
6
  DWORD     dwServiceType,
7
  DWORD     dwStartType,
8
  DWORD     dwErrorControl,
9
  LPCWSTR   lpBinaryPathName,
10
  LPCWSTR   lpLoadOrderGroup,
11
  LPDWORD   lpdwTagId,
12
  LPCWSTR   lpDependencies,
13
  LPCWSTR   lpServiceStartName,
14
  LPCWSTR   lpPassword
15
);
Copied!
Lsassy smb.py SCMR code snippet
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 :
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
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.
All these capabilities will be incorporated in the next major release of the tool
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.
ImagePath modification upon the creation or modification of a service
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.
Event ID 5145 remote access to comsvcs.dll
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\.
rundll32.exe accessing lsass.exe
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* ORChangeServiceConfig*
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
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.
Logic Building Blocks
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.
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:
4 Levels Of Data Maturity Every Manager Must Know | COMPUTD
COMPUTD
Creating and Starting a Windows Service Remotely Using NtObjectManager Via Remote Procedure Calls (RPC) Over SMB
Open Threat Research Blog
Service Control Manager - Win32 apps
docsmsft
[MS-SCMR]: Service Control Manager Remote Protocol
docsmsft
MiniDumpWriteDump via COM+ Services DLL
modexp
ChangeServiceConfigA function (winsvc.h) - Win32 apps
docsmsft
GitHub - Hackndo/lsassy at 3.0.0
GitHub