Analytics
The ability to think like an attacker.
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.
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:
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.
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.
A combination of both.
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.
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.
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 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.
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.
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.
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.
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.
- Winlogbeat Agent and Sysmon for endpoint telemetry
- Zeek for network telemetry.
- Elastic Stack for centralized logging and correlations
- 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.
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
LOLBintechnique based onCOMSVCS.DLL. - The service is configured to start on demand when the
StartServicefunction is called
Logic is valid. However, detection resilience is very low
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-98F038001003and 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
OpenSCManagerWfunction 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
CreateServiceWfunction
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
);
Lsassy smb.py SCMR code snippet
comsvcs.dllexports a function calledMiniDumpWwhich can be used by rundll32 to dump process memory.comsvcs.dllaccepts 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 optionfull.- The
MiniDumpfunction requires a target process ID. Process discovery technique is expected. In this casetasklist.exeis used to get LSASS process ID. - The
MiniDumpfunction call can also be achieved by function reference number#24. - The execution of this method requires
rundll32.exeto request a handle toLSASS. AnEID 10will be generated withcomsvcs.dllin 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 :
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:
CreateServiceWORCreateServiceA - 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 : (
MiniDumpOR#24) ANDfullAND*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
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.dllto evade hardcoded string-based command-line detections. - 3.The attacker can also adopt the execution of obfuscated and encoded command lines through
cmd.exeorpowershell.exe.
All these capabilities will be incorporated in the next major release of the tool
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
QueryServiceConfigto query the configuration of targeted service the attacker wants to change followed byChangeServiceConfigfunction to apply that change instead ofCreateService. For detection opportunities we can rely on EID 5145 but Zeek'sDCE-RPCevent log has high Event Decisiveness and Traceability since it provides the exact endpoint operation and not just the accessed RPC endpointsvcctl. - 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
ImagePathmodification underHKEY_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.dllfile and rename it the attacker needs to reach it first. So an EID 5145 will be generated in this case withcomsvcs.dllinRelative Target Namefield. 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 Tracefield richness and thesource process GUIDthat can be used for correlation purposes (In my case Elastic Security uses this field to create process trees visualizations).rundll32.exeaccessinglsass.exealone is a rare behavior. However, you can increase the precision of your analytic by looking forcomsvcs.dllinCall Traceor any anotherdllfrom a location other thanC:\Windows\System32\.
rundll32.exe accessing lsass.exe
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.
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.
Last modified 1yr ago