Background
The primary role of any SOC is to prevent, detect and respond to perceived cyber threats within an environment. A SOC is made up of people, processes, and technology. All these components need to be used together to fulfil the mandate of the SOC. Different methods are employed to detect perceived cyber threats within an environment. On hosts, most of these methods leverage the use of an endpoint agent. Endpoint agents use signature-based detection, heuristics, and user behaviour analysis to detect threats. These technologies offer sufficient detection capabilities when defending against less sophisticated threat actors; however, more sophisticated groups have been known to bypass these technologies by disarming them, and rendering them ineffective and unable to send telemetry back to the SIEM solution. At this point, the security analysts would have no visibility over the endpoint and no way to be alerted of the active attack. Through the course of a number of insights pieces, we would like to introduce a couple of these topics and explore some options available to the SOC. The first one we are going to be talking about is Active Defense.
Threat Hunting and Active Defense could be used to supplement the threat detection capability of a SOC. Although these methods rely on a strong people component within the SOC, they are inexpensive to implement and often produce high-fidelity alerts. At a fundamental level, we alert on actions taken by an attacker, that would be classified as malicious while completing the kill chain. This piece of work aims to introduce security operations personnel to the concept of Active Defense. While many organisations have successfully integrated Threat Hunting into their security operations, we have not observed the same with Active Defense.
What is Active Defense?
Active Defense or Active Cyber Defense is a method used by security operations teams to augment their threat detection and cyber threat intelligence (CTI) capabilities by using deception technologies to closely monitor, misdirect and or frustrate threat actors targeting their environments. The concept leverages the defender’s knowledge of their environment to carefully set “traps” within the environment. A high-fidelity alert is sent to the security operations team after any one of these traps has been triggered.
The goal of any Active Defense deployment should be to detect, disrupt, delay, or divert a threat actor, increasing the cost for the threat actor to realise their objectives while buying time for the defense teams to detect and respond to the perceived threat.
An example of popular implementations of deception technologies is listed below.
| Name | Description | Example Use Cases |
| Honeypot | A host with exposed and possibly vulnerable services used to lure threat actors | When a honeypot is exposed to the internet it can be used as a tool to collect CTI. When it is placed inside the network honeypots can be used by defenders as a decoy |
| Honeynet | A network of honeypots running vulnerable services | A honeynet could be used as a staged environment to monitor a threat actor’s actions |
| Honeyfile | A file carefully placed in a threat actor’s path to illicit interaction | A honeyfile can be used to alert network defenders to a breach |
| Honey Credentials | These are comprised of honey accounts, tokens, hashes, and certificates | Honey credentials can be used to redirect a threat actor towards a honeypot or honeynet in-order to frustrate the threat actor |
Deployment Strategies
Deceptive technologies should be deployed to disrupt the threat actor’s attack chain by feeding them false information at different phases of the attack. Suppose the technologies are detected by the threat actor, at worst. In that case, this strategy could result in the threat actor taking more time to verify each piece of information they acquire, giving defenders more time to detect and respond. If the deception goes unnoticed, the security operations team could use the information obtained from monitoring the threat actor navigating the environment to feed into their threat intelligence. Valuable insights into the actor’s Tactics Techniques and Procedures (TTPs) can subsequently be used to create a strategy for response. This data also exposes the threat actor’s capabilities and allows defenders to respond accordingly.
Defending Your Crown Jewels
Before deploying deceptive technologies within the environment, an audit should be performed. The audit should identify which hosts within the network or environment in question are the most important to the organisation. Once this audit has been completed, a threat modelling exercise should be performed. This exercise should focus on identifying avenues a threat actor could take to compromise any high-value assets within the network. Once the attack paths have been identified, defensive measures implemented to mitigate the risk associated with an attack path should be assessed to identify high-risk assets.
Example – Ransomware Detection
If for example, an organisation is concerned about a new strain of ransomware brought to their attention by CTI feeds, they could use Active Defense to augment their current detection capability. For the purposes of this exercise, I pre-selected a strain of CONTI ransomware (SHA256: 004ede55a972e10d9a21bcf338b4907d6eed65bf5ad6abbbd5aec7d8484bdedf) to demonstrate how one could design “traps” for a specific ransomware family. A more generalised approach could be taken where a design solution is created from the combined results of analyses of several malware strains.
Figure 1: CONTI characteristics – pestudio1
Figure 1: CONTI characteristics – pestudio1Defenders are able to leverage information and data obtained from attacks observed in other organisations within the same industry to detect and prevent similar local attacks through CTI. When artifacts such as malware are retrieved from a live threat, defenders should take advantage of this information by designing detection and response mechanisms within their own environments. While creating blocking rules using host and network-based indicators of compromise (IOC) such as IP addresses, URLs and hashes would be effective in detecting and preventing less sophisticated threat actors, this would not deter more sophisticated actors who would be able to alter these IOCs. A more effective approach would be to use the malware’s characteristics against its operators.
1. Behavioural Analysis
The sample chosen for this exercise dynamically loaded modules. By setting a breakpoint on the GetProcAddress API it was possible to determine which modules would be loaded. Breakpoints were set on the following Windows APIs:
- GetLogicalDriveStringsW
- GetDriveTypeW
- FindFirstFileW
- NetShareEnum
- GetIpNetTable
Identifying Local Targets – GetLogicalDrivesStringsW and GetDriveTypeW
DWORD GetLogicalDriveStringsW(
[in] DWORD nBufferLength,
[out] LPWSTR lpBuffer );
CONTI ransomware identified local drives to encrypt through the GetLogicalDrivesStringsW API. This API is a wrapper to the GetLogicalDrives API which loops through each letter in the alphabet, from A to Z, to determine the drive letters of local volumes. After the GetLogicalDrivesStringsW API returns, a null-terminated string containing the identified logical drive letters is stored in the location specified as the 2nd argument passed to the function. Note that the list is sorted alphabetically.
Figure 2: Contents of lpBuffer after the function returns – x32dbg2
Figure 2: Contents of lpBuffer after the function returns – x32dbg2UINT GetDriveTypeW(
[in, optional] LPCWSTR lpRootPathName );
Each identified drive letter is then passed as the lpRootPathName argument to determine the type of drive. The drive is marked for encryption if GetDriveTypeW determines the drive to be removable, fixed, remote or a RAM disk.
Figure 3: Drive type decision tree
Enumerating Target Files to Encrypt – FindFirstFileW and FindNextFileW
HANDLE FindFirstFileW(
[in] LPCWSTR lpFileName,
[out] LPWIN32_FIND_DATAW lpFindFileData );
Once a drive has been marked for encryption the malware enumerates through the filesystem using FindFirstFileW and FindNextFileW. The drive letter is passed as the first argument. This instructs the system to enumerate through each directory and file within the root of the drive recursively while the malware encrypts each file. FindFirstFileW and FindNextFileW cycle through the file objects in alphabetical order with files starting with symbols getting encrypted first.
Figure 4: Files encrypted in alphabetical order
Identifying Remote Targets – GetIpNetTable and NetShareEnum
IPHLPAPI_DLL_LINKAGE ULONG GetIpNetTable(
[out] PMIB_IPNETTABLE IpNetTable,
[in, out] PULONG SizePointer,
[in] BOOL Order
);
After CONTI has discovered locally mapped drives, it looks to target remote shares on the network. The malware uses the GetIpNetTable API to discover new hosts to target. The API retrieves the host’s local Address Resolution Protocol (ARP) cache which contains a list of IP addresses on the network. Note that the listed IP addresses are sorted in incrementally.
Figure 5: ARP entries
Figure 5: ARP entriesNET_API_STATUS NET_API_FUNCTION NetShareEnum(
[in] LMSTR servername,
[in] DWORD level,
[out] LPBYTE *bufptr,
[in] DWORD prefmaxlen,
[out] LPDWORD entriesread,
[out] LPDWORD totalentries,
[in, out] LPDWORD resume_handle );
The malware then passes these IP addresses to the NetShareEnum API through the server name argument. The API returns information about the remote host’s SMB shares.
Figure 6 – ARP entry passed as argument
Figure 6 – ARP entry passed as argumentThe Solution
With the information obtained from analysing the ransomware sample, we could influence which file gets encrypted by the malware first. We could redirect the ransomware to encrypt a file we are monitoring for changes located on a remote host that is mapped locally as a drive on the infected system. This could alert the SOC of an ongoing attack where endpoint agents have been bypassed by the ransomware operators.
The Design
To create a fallback detection mechanism for ransomware within a network consider the following:
| Honeypot |
|
| Honeyfile |
|
Conclusion
Active Defense should be implemented together with existing detection and response capabilities. The low maintenance overhead and high-fidelity alerts associated with such technologies make them attractive to defenders. Correct implementation of these techniques is dependent on their configuration and how likely it is for a threat actor to encounter them within the network. A balance between making the decoys look attractive to the threat actor and not overselling the decoys must be achieved for successful deployment.
It should be stressed that Active Defense should not be the only method to detect threats within a network, rather these defences should supplement traditional detection methods.
