Social Media
GitHub

Analytics

The ability to think like an attacker.

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 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]

  • 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.

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

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 :

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.

  • 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\.

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.

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:

PreviousExecutionNextELK4QRadar

Last updated