How to learn how to build a Kilchain

20.11.2023

Security Vision

The word ‘killchain’ (or more precisely, several words: The Cyber Kill Chain) first appeared as a term back in 2011, when the American company Lockheed-Martin first proposed to build the events recorded in the infrastructure into a single attack chain. The chain was quite simple and included only 7 links: reconnaissance, arming, delivery, operation, installation, management, and action. It was essentially a response to increasingly sophisticated hacker attacks that used increasingly sophisticated tools and multi-pronged attack tactics.

The approach of dividing the attack into stages proved to be very popular, but it was not without its flaws. For example, Lockheed-Martin's Kilchain did not take into account the internal attacker attacking from within the infrastructure. Accordingly, other players have tried to develop and improve this method. Thus, in 2013, MITRE offered its own variant, presenting a sequence of 14 tactics. Later, cybersecurity expert Paul Polls proposed a hybrid variant that combines and extends the Lockheed-Martin and MITRE methodologies, known as The Unified Kill Chain.

Let's discuss the pros, cons and pitfalls of the killchain as such, as well as try to understand a real-life example of building an attack chain.

Approaches and techniques for building an attack timeline

Killchain is based on the attack timeline, which is its most important component. Therefore, in the process of responding to IS incidents, it is necessary to determine the attacker's timeline, the attack surface (compromised hosts, accounts), vulnerabilities, tools and TTPs used by the attacker. The final attack timeline is built by linking the IS incidents involved in the attack by key attributes: IP addresses/names of attackers and compromised hosts, compromised accounts, vulnerabilities on hosts, hacker tools, TTP.

A MITRE ATT@CK attack matrix is overlaid on the generated timeline, which allows the final attack killchain to be constructed by mapping each step of the attack timeline to the corresponding tactic/technique in the MITRE ATT@CK matrix.

Building the attack killchain can be automated or manual. In the first case, this will be done by SOAR/XDR products, which, in addition to performing active actions to contain and eliminate the consequences of an attack, correlate the detected IS incidents by orchestrating and aggregating data from various sources. Such sources include: SIEM systems, logs of protection systems (DOE, IDS/IPS, WAF, proxy servers, mail gateways, antivirus, sandboxes, DLP, IDM/PAM, NAC, etc.), system logs (Windows Eventlog, Linux auditd/syslog), application logs (web servers, mail, file servers, DBMS, ERP, CRM, etc.), and logs of switching equipment (switches, routers, Wi-Fi access points).

The above mentioned SOAR/XDR class systems will perform all necessary analyses and build the final timeline and killchain of the attack in a convenient form, as well as provide recommendations on how to respond to each stage of the attack. The following examples demonstrate this.

Automated approach

This example shows how the attack evolved from the initial access stage (exploitation of the Log4Shell critical vulnerability) to the compromise of the domain controller (exploitation of the PrintNightmare critical vulnerability), followed by an attempt to launch the encryptor across the entire domain with account privileges from the Domain Admins group.

Mapping each step of the attack timeline to the MITRE ATTACK matrix resulted in the following killchain.

Manual approach

When no such solutions are at hand, we have to solve this problem manually. For this purpose, the following manual attack timeline building approaches should be resorted to:

1) Analysing and linking the IS incidents received from the SIEM by common key attributes.

In this case, the SIEM will produce a list of IS incidents for the time period in question, grouping similar ones. The IS incident card will highlight the key attributes (IP addresses/names of hosts, accounts, vulnerabilities, etc.) that should be used to logically link the incidents and build them into a single attack chronology.

2) Retrospective search for behavioural threat indicators in SIEM logs, based on knowledge of the most relevant TTPs, vulnerabilities, indicators of attackers' hacker tools and VPOs, so-called Threat Hunting indicators. The approach is based on building hypotheses of the presence of behavioural indicators (host, network) in the logs with subsequent confirmation or refutation of these hypotheses until the full timeline of the attack is built.

Host-based behavioural indicators include characteristic registry keys, process startup strings, named channels, services, scheduler tasks, library names, requested process access rights, etc. Network behavioural indicators include characteristic patterns (presence of obfuscated, encoded, encrypted content) in the headers and body of network traffic packets, the size of network packets and their headers, the frequency of their sending, handshake parameters when establishing an encrypted session with malicious C&C servers, etc.

It is not uncommon for SIEM logs to be insufficient, especially when dealing with an experienced attacker who is able to hide his actions and evade detection by an antimalware system. In this situation, to identify attack indicators, we have to resort to low-level analysis of OS artefacts, such as the file system, registry, memory of compromised hosts, OS logs and logs, and network traffic (if it is recorded by DOE or NTA systems). The topics of host and network forensics require separate attention, which will be covered in the following articles.

In practice, this approach is used only to a limited extent due to its high labour-intensiveness and the requirements of high expertise of the analyst, which consists in the knowledge of the most relevant tactics, techniques and tools of attackers, the ability to detect and correlate their traces in the ‘raw’ stream of host and network events, as well as the ability to use computer forensics tools.

Combined approach

The most effective approach in our opinion, which we will consider further on the example that took place in real practice.

In a monitored network, SIEM tools registered incidents in the form of mass attempts to exploit vulnerabilities from node 93.38.176.186. Some time later, an incident was registered in the form of a network access to the malicious IP 185.202.174.91 from the monitored node 83.1.1.100 DMZ zone. Both nodes 93.38.176.186, 185.202.174.91 were attributed as C&C servers of the Cobalt Strike hacker software via feeds loaded into SIEM TI. It was necessary to assess the infection surface and then build an attack timeline, but there were no other indications of infection with this VPO, so the decision was made to conduct Threat Hunting on Cobalt Strike.

Using numerous Cobalt Strike detection guides, the following attack indicators were identified and retrospectively searched the SIEM logs in the vicinity of the detected incidents, resulting in the following attack timeline.

The following are the Elastic (KQL) search queries for attack indicators

1) Launching the Rundll32 system process without parameters (Windows Eventlog, process creation event): Execution stage, Command and Scripting Interpreter technique (T1059) by Mitre Attack matrix:

event.provider:Microsoft-Windows-Security-Auditing and event.action:created-process and process.name: rundll32.exe and process.command_line : *\\\rundll32.exe

2) Privilege escalation to NT AUTHORITY\SYTEM system account via Named Piped Impersonation technique (Windows Eventlog, process creation event) for the purpose of possible further account compromise: Privilege Escalation stage, Access Token Manipulation technique (T1134):

event.provider:Microsoft-Windows-Security-Auditing and event.action:created-process and process.name: rundll32.exe and process.command_line : C\:\Windows\\\system32\\\cmd.exe /c echo * \>; \\\\.\\\pipe\\*

3) Horizontal propagation using psexec method with service creation and a powershell command line in the file path of the service (Windows System security log, service creation event, event code 7045): Lateral Movement stage, Remote Services technique (T1045):

event.provider:Service Control Manager and event.code:7045 and winlog.event_data.ImagePath :%COMSPEC% /b /c start /b /min powershell -nop -w hidden -encodedcommand*

4) Command communication with central node and controlling C&C server via named pipes (Windows Sysmon log, named pipe creation event, event code 17): Command and Control stage, Application Layer Protocol technique (T1071):

event.provider:Microsoft-Windows-Sysmon and event.code:17 and file.name : (\\msagent_* OR \MSSE-*-server OR \postex_* OR \\status_* OR \mypipe-f* OR \mypipe-h*)

Conclusions

In order to build an attack chain, we need information about unauthorised attempts to interact with the infrastructure and tools with which to obtain and process this information. Ideally, these are SOAR/IRP or XDR class systems that process much of the information automatically.

For example, IRP from Security Vision automatically analyses the flow of events from SIEM, groups them by itself, building a chain of suspected attacks, and even determines to which sections of MITRE ATT&CK the detected incidents may belong, and provides recommendations on how to eliminate the threat. All a person has to do is to get into the situation and either take the necessary actions to respond to the threat directly in the attack card interface, or find out that the actions were legitimate and mark the attack as False Positive. By the way, some of the response actions can be performed automatically in accordance with the settings of security policies.