Mapping Security Information and Event Management (SIEM) Rules to Tactics and Techniques of the MITRE ATT&CK Framework

Engineering and Architecture Department
Computer & Electronics Engineering
Mapping Security Information and Event
Management (SIEM) Rules to Tactics and
Techniques of the MITRE ATT&CK Framework
Master’s Thesis
Graduating
Antonio Procentese
Supervisor
Prof. Alberto Bartoli
Co-Supervisor
Ing. Lorenzo del Sordo
____________________________________
Academic Year 2022-2023

Contents
Abstract ................................................................................................................................................4
Introduction..........................................................................................................................................5
Literature Review.................................................................................................................................7
Premise.............................................................................................................................................7
Cyber Kill Chain..............................................................................................................................7
MITRE ATT&CK ............................................................................................................................9
SIEM Systems................................................................................................................................11
Premise.......................................................................................................................................11
Workflow....................................................................................................................................11
Challenges of SIEM systems .....................................................................................................12
SPL, Splunk and Rules.......................................................................................................................13
Mapping of the rules ..........................................................................................................................14
The mapping process .....................................................................................................................14
Exceptional case during the mapping process ...............................................................................17
Examples of rules...........................................................................................................................17
Premise.......................................................................................................................................17
Windows Logs Event Clearing ..................................................................................................17
Possible Kerberoasting...............................................................................................................19
MITRE Coverage Assessment ...........................................................................................................22
Data explanation and SPL query....................................................................................................22
Interface .........................................................................................................................................23
Implementation ..............................................................................................................................23
Discussion on the obtained coverage.............................................................................................27
An alternative illustration...............................................................................................................28
Conclusions........................................................................................................................................31
Appendix............................................................................................................................................32
Feasibility analysis of Splunk Attack Range..................................................................................32
Bibliography.......................................................................................................................................34

Abstract
Il MITRE ATT&CK è il framework di riferimento utilizzato in ambito cybersecurity per modellare un
attacco informatico. Secondo il modello, un attacco si compone di più fasi, dette tattiche, che
rappresentano l’obiettivo che un attaccante vuole ottenere. Ciascuna di queste fasi può essere
portata a termine attraverso le cosiddette tecniche, che sono ciò che nella pratica rende possibile la
realizzazione di un obiettivo.
ATT&CK mette al servizio dei professionisti della sicurezza informatica suggerimenti pratici relativi al
rilevamento dell’incidente e alla mitigazione del rischio per ciascuna tecnica illustrata, in modo tale
da agevolare l’identificazione e la risposta alle minacce. Questa caratteristica rende tale framework
uno strumento particolarmente efficace nel miglioramento dei sistemi SIEM (Security Information
and Event Management).
Un SIEM (Security Information and Event Management) è uno strumento progettato per raccogliere
e analizzare log provenienti da diversi dispositivi all’interno di un’organizzazione. La funzionalità
principale di un sistema del genere in questo contesto è quella di rilevare gli incidenti di sicurezza.
Ciò viene fatto per mezzo delle cosiddette regole, che sono istruzioni usate per analizzare gli eventi
tracciati da uno o più log. Il risultato di questa analisi è un booleano: se il valore risulta true, viene
generato un alert, cioè una notifica creata a seguito del rilevamento di un potenziale incidente di
sicurezza. Quelle regole che analizzano e correlano più eventi prendono il nome di regole di
correlazione. Ci si può riferire alle regole con il termine detection.
Questa tesi di laurea, svolta in collaborazione con Security Reply, ha l’obiettivo di andare a migliorare
la comprensione degli incidenti di sicurezza, per dare un aiuto concreto agli analisti di sicurezza che
lavorano sugli alert che il SIEM fa scattare a seguito del verificarsi di eventi potenzialmente malevoli.
Nel concreto, sono due i risultati principali. Il primo è la mappatura di un sottoinsieme di regole
utilizzate in un SIEM aziendale; tale procedura ha portato all’identificazione delle tattiche e tecniche
da associare a ciascuna regola. Il secondo consiste nello sviluppo di una query specifica per Splunk
– il SIEM utilizzato – per valutare la copertura MITRE delle regole trattate, ossia quante tecniche e
quali sono coperte da una detection.
Conoscere la copertura difensiva è di fondamentale importanza per tutte le organizzazioni che
mirano a migliorare le proprie capacità di rilevamento, in modo da essere al corrente delle lacune di
sicurezza e agire di conseguenza.

Introduction
The MITRE ATT&CK framework is currently the reference model for describing how a cyber-attack is
carried out [1], [2]. Using its terminology, it consists of several phases, called tactics, representing
the high-level objective an attacker wants to achieve. Each tactical objective can be accomplished
by means of different practical methods, called techniques. For each technique, ATT&CK provides
operational detection and mitigation strategies defenders can use to identify and respond to threats,
which is why such a framework plays a crucial role in enhancing SIEM (Security Information and
Event Management) systems.
A SIEM system is a tool designed to collect and inspect logs coming from different devices with the
aim of detecting security incidents (or threats). Such an analysis is carried out by means of the so-
called rules, that are instructions used to examine events coming from one or more logs. The output
of the analysis is a boolean: if it is valued as true, an alert, that is a warning generated upon the
detection of a potential security incident, is generated. Those rules that inspect and correlate
multiple events are called correlation rules. Rules can be also referred to as detections.
This thesis project yields two main outcomes. The first one is the manual mapping of a subset of
existing rules according to the framework. Such rules are part of a wider set of rules actually used in
a corporate SIEM system. This process involved the identification of tactics and techniques to be
associated with each detection, with the goal of enriching the associated security incidents with
valuable information. In this way, cyber defenders can get a more comprehensive understanding
regarding the alerts triggered by the SIEM. The second outcome involves the creation of a query,
specific for Splunk (the SIEM in use), for evaluating the MITRE coverage of the available set of rules,
that is how many techniques – and which ones - are covered by a detection with respect to those
listed in the framework. It turns out that such a query is suitable for assessing the coverage of any
set of mapped rules, thus having an immediate practical applicability. Any organization aspiring to
improve its detection capabilities can benefit from knowing the coverage, to find out what are the
security gaps with respect to the framework and act accordingly. It is worth mentioning that a more
straightforward approach for assessing the coverage is offered in the paid Enterprise Security version
of Splunk [47]. However, it could not be used due to cost constraints; for this reason, it was
developed a free and alternative approach.
The project was remotely conducted within the Incident Response Team at Security Reply, a
consultancy firm in the cybersecurity field. The focus was exclusively on the detection part of a
security incident, rather than the response to it.
The realization of this project can be outlined as follows:
- Literature review on Cyber Kill Chain (first widely used model [2]), MITRE ATT&CK and SIEM
systems.
- Acquisition of the basics of Splunk and the Splunk Processing Language (SPL) in which the
detections to be mapped are expressed.
- Mapping of the rules according to the MITRE framework.
- Development of a Splunk query to assess the coverage.

- Feasibility analysis of Splunk Attack Range, a tool for simulating attacks and testing detection
capabilities (prematurely interrupted due to cost constraints).
The work was conducted on an HP Pavilion laptop running Windows 11 Home. Splunk version 9.1.0.1
was employed, with a free developer license. The decision to opt for Splunk over other SIEM systems
was made by the company. The mapping was performed by populating an Excel file listing the rules.
Such a file constitutes an input for the aforementioned query.
The rest of the document is organized as follows: in the Literature Review, the Cyber Kill Chain and
MITRE ATT&CK frameworks are presented, along with the basic general aspects of SIEM systems;
furthermore, the decision to opt for ATT&CK rather than CKC for enhancing the SIEM in use is
explained. The chapter Splunk, SPL and Rules provides a brief introduction of those mentioned
concepts. The Mapping of the Rules section includes the detailed description of what the mapping
process exactly consisted of. Examples or real-world rules and their analysis are provided as well. In
the MITRE Coverage Assessment part, the query for determining the coverage is analyzed in detail,
clarifying what its purpose is and how it is structured. The Conclusion summarizes the outcomes of
this thesis work, with also considering how the Incident Response team can leverage them for
further improvements on their SIEM system. Finally, In the Appendix, a complementary part of the
work is discussed: Feasibility Analysis of Splunk Attack Range, describing the attempt of performing
attack simulations and testing the effectiveness of the detections.

Literature Review
Premise
Before dealing with the mapping process and the MITRE ATT&CK coverage assessment, it was
necessary to gain some theoretical knowledge to lay the fundamentals of the whole project. This
was done by studying both the Cyber Kill Chain (CKC) and the MITRE ATT&CK frameworks; also the
concept of SIEM is part of this examination. This section provides a concise overview of these topics
at a high-level of abstraction. The in-depth discussion of the technical details behind the execution
of a specific attack-phase is not the focus of this review.
Cyber Kill Chain
The Cyber Kill Chain was introduced the first time in 2011 by Lockheed Martin [24], company
operating in aerospace and defense. The name comes from the military jargon, as the term kill chain
indicates the process to target and engage an adversary [54].
The framework breaks down cyber-attacks in multiple consecutive stages. In this way, defenders can
focus on prevention and mitigations of smaller and more manageable problems. According to CKC,
an attack consists of 7 different phases [12], that can be grouped in three macro-categories [21],
listed below.
● Preparation phase
● Reconnaissance: collection of information about the target and identification of
vulnerabilities.
● Weaponize: preparation of tools to exploit security vulnerabilities discovered in the
previous phase. A malware which provides the attacker with hidden remote access is
bound with an exploit, that is what triggers its installation. An example of exploit can
be a .docx file opened by the victim by means of a vulnerable software.
● Incident Phase
● Delivery: the malicious payload is sent to the victim, often through the download of
appealing content or the insertion of an infected USB key.
● Exploitation: the malware is installed and executed within the target’s environment.
In order for this stage to succeed, three conditions must simultaneously be satisfied:
1. The victim-side system matches the one for which the exploit was created.
2. The target has not installed security updates that prevent the malware from
working.
3. Antiviruses and mechanisms defenses are circumvented.

● Installation: additional malware installation to gain persistence, that is maintaining
the unauthorized access.
● Active Intrusion Phase
● Command and Control (CnC): commands are executed on the target system. This
execution generates traffic, whose analysis can detect communication patterns
among the infected machines. Techniques that make this communication resemble
legitimate traffic are used.
● Act on Objectives: the final objective is achieved (e.g. data theft, or data encryption
leading to ransom demands)
Figure 1: Cyber Kill Chain representation [13]

One notable instance of practical application of the CKC is presented by Tarnowski et al., with a case
study in which the model has been employed for protecting a Metropolitan Area Network [12].
Due to the rigid arrangement of the phases and the lack of granular details of attacks [25], the CKC
was not employed to execute the practical part of this project. The MITRE ATT&CK was chosen
instead, whose description is provided in the upcoming section.
MITRE ATT&CK
The MITRE ATT&CK was introduced in 2013 by Mitre Corporation, a not-for-profit organization
supporting U.S. government agencies in fields like defense, healthcare and cybersecurity [4].
This framework defines tactics, techniques and procedures (TTPs) used by attackers (called, in this
context, adversaries). Tactics are the high-level objectives of the specific part of the attack being
carried out, whereas techniques represent the concrete way a tactical objective is achieved.
Procedures are detailed steps for executing a technique, that is their actual implementation [3]. Not
always all tactics are simultaneously part of an attack, as well as they are not necessarily executed
in sequence [2]. A technique is related to one or more tactics. An example: the Valid Accounts
technique, used by adversaries to obtain and abuse credentials of existing accounts, is associated
with several tactics [22]: Initial Access, the early stage of an attack in which adversaries gain foothold
within the target network; Persistence [35], whose aim is to maintain the unauthorized access;
Defense Evasion [34], consisting of techniques to avoid detection throughout the compromise, and
Privilege Escalation [45], representing the gaining of higher-level permissions on a system or
network.
Some techniques can be further split into sub-techniques, which are different variations of the same
one. The Brute Force technique, listed under the Credential Access tactic [52], is split in 4 different
sub-techniques: Password Guessing, Password Cracking, Password Spraying and Credential Stuffing.
There are three main application domains: Enterprise (the focus of this thesis), Mobile and ICS
(Industrial Control Systems).
MITRE does not describe cyber-attacks by means of sequential steps, unlike the typical CKC chain
structure; the overall representation of attacks is done with a matrix [14]. There is a different matrix
for each aforementioned application domain.
The framework is regularly updated with new techniques based on real-world observations [3],
which is why over the years different versions of MITRE have been published. The one in use for the
practical part of the thesis (mapping of the rules and coverage evaluation) is the v14.1; it comprised
fourteen tactics and hundreds of techniques (234, sub-techniques excluded), taking as reference the
latest version as of December 2023.
For each technique, the MITRE ATT&CK offers mitigation and detection strategies, thus giving
practical suggestions to the defenders supposed to write new rules or refine existing ones. For this
purpose, it is specified which logs must be collected and monitored to detect the usage of a specific
technique.

Some key practical applications of the MITRE ATT&CK are briefly listed below, to provide a better
understanding about the employment of the framework:
● Reference model: the framework is used as a de-facto standard in describing threats and
attack campaigns disclosed by cybersecurity professionals as part of their CTI (Cyber Threat
Intelligence) activities [14]. CTI is the practice of collecting and analyzing data to identify
security threats, assisting cyber-defenders in tackling them.
● Integration with other frameworks:
● ATT&CK is part of a bigger project still developed by MITRE, called CALDERA [14], [15] an
open-source security platform that provides automated security assessments [16], [17].
● The ICS matrix has been combined with another security framework developed by the
NIST (National Institute of Standards and Technology), to create the Cyber Threat
Dictionary [14],[18], security measure specifically designed for protecting US critical
infrastructures.
● Research:
● Bagui et al. developed a ML-based framework for detecting Reconnaissance [49] and
Discovery [48], two MITRE tactics [19].
● Sahu et al. considered a subset of the MITRE ATT&CK matrix for cloud security purposes
only [20].
● Cloud Security: Microsoft Azure security measures have been aligned with ATT&CK. [14]
● Evaluation of products: security tools are assessed for their effectiveness by testing them
against MITRE tactics and techniques. [14]
A more complete and exhaustive presentation about MITRE’s application in the industrial and
academic fields is presented by Roy et al. [14].
Figure 2: Matrix of ATT&CK (tactics only) [15]

Figure 3: Matrix of ATT&CK (tactics, techniques) [2]
As discussed in the previous section, the Cyber Kill Chain is not suitable for describing the huge
variety of attacks with respect to the MITRE framework. However, it is worth mentioning that
ATT&CK is based on observations of attacks made in the U.S., Europe and other developed countries.
Therefore, tactics and techniques used by attackers in other parts of the world may not be
represented within the matrix [14].
This document is not meant to provide a complete description of tactics and techniques, which can
be found online [3].
SIEM Systems
Premise
The following paragraph contains essential information to understand the content of this section.
An alert is a warning generated by the SIEM system in response to an event detected as a potential
security incident. A security incident, also referred to as threat, is an event (or a set of events) that
triggered the alert. It is up to the security analysts to further investigate the nature of the alerts, to
discriminate between false positives and actual security incidents.
Based on its severity, a security incident is classified as having low, medium or high priority, whose
distinction depends on the specific organization and on the potential impact it can imply. An alert
concerning a high priority incident is called alarm.
The concept of rule and its output has already been defined in the Introduction.
Workflow
A SIEM system analyzes and correlates logs to understand what events occurred within a network.
The log sources may be all the components of an IT environment, like firewalls, DDoS protection

tools, web servers and so on. Not all logs are important for detecting a security incident, which is
why security teams select a subset of them which is of interest for a specific organization. This
targeted approach also serves to reduce licensing costs.
The workflow of a SIEM can be summarized as follows:
● Raw log files generated from different sources are continuously collected by the SIEM.
● Since logs coming from different sources likely have their own format depending on the
vendor, a normalization phase is needed to get uniform and structured data. This process has
the purpose of making the analysis easier.
● A set of rules, designed and implemented by security experts over time, is run to search for
security incidents. It is important to point out that security vendors providing a SIEM system
usually include a set of generic essential rules to be used as a starting baseline of defense.
● The alerts resulting from the executed rules are ranked by means of a numerical score
assigned to them. Such a score is based on the severity of the associated security incident,
which essentially depends on the potential impact such an event can have against the
organization.
● Logs are stored in a separate redundant location as a fallback option in case of hardware
failure or physical disaster.
Figure 4: typical SIEM architecture [23]
Although a SIEM system is usually active 24/7, the set of rules is executed with a periodic frequency,
usually every 5-15 minutes. It is up to the security analysts to determine the exact frequency to
adopt.
Challenges of SIEM systems
● Typically the volume of alerts, and so of events identified as potential security incidents, is
huge; however, just a limited subset of them can be properly taken care of [23],[55].
● Furthermore, the majority of events identified as potential security incidents are low-priority
or false positives. The presence of false positives specifically makes a SIEM system a tool to
be continuously optimized: it means that if such events are incorrectly interpreted as security

incidents, the rule that triggered the alert must be modified. These changes require many
iterations, and in general the optimization of a rule is a long process that reduces the
presence of false positives, but it very rarely eliminates them entirely. For this reason, SIEM
systems are far from being setup-and-forget tools [23].
● Another challenge is represented by the continuous need of providing SIEMs with rules that
reflect new attacks, discovered on an hourly basis [23].
SPL, Splunk and Rules
As mentioned in the Introduction, the syntax in which the detections are expressed is the SPL (Splunk
Processing Language), proprietary language developed by Splunk for querying and analyzing data
ingested within their platform. It is used to get insights from the logs, either collected in real time or
previously stored.
Splunk is a software platform that allows to search and correlate data from a variety of sources [39].
Different kinds of licensing are offered; the Enterprise Security (ES) is the one having the capabilities
of a SIEM. Such a version is the most suitable for detecting security incidents and consequently
managing the response. The Enterprise Security version of Splunk in particular offers the possibility
to map the rules by means of suitable integrated tags, that essentially are labels that can be
appended to the detections. However, no ES license could be obtained for this project, implying that
the mapping process was done on an Excel file and not in-app. Such a file was created by the
company that decided what rules to include in there. More details about the structure of this file as
well as its usage for carrying out the mapping are provided in the next section, Mapping of the rules.
As said, rules examine events coming from one or more logs. The subset of rules inspecting and
correlating multiple events are called correlation rules. The term originates from the correlation that
is performed among events. Rules look for defined patterns occurring within a network. Their output
is a boolean, whose value is true when the pattern of interest is found and false otherwise. When
the search finds a pattern of interest, that in this context corresponds to any event that may
constitute a security incident, a response is required to handle it. Based on the nature of such an
incident and on the internal organization of security teams, responses can either be manual or
automated. An automated response, that in Splunk takes the name of Adaptive Response Action, is
a set of predefined actions implemented within the SIEM that are triggered upon detecting a security
incident. Sending an instruction to the firewall to block connections from a specific IP address or to
block the attempts of connections to specific websites known for phishing activities, constitute an
example of adaptive response actions.
The thesis author had no previous knowledge about SPL, Splunk and rules: the necessary
fundamentals to get this task done have been autonomously acquired during the period of
collaboration with the company, mainly by means of official tutorial provided by the Splunk website
[29].

Mapping of the rules
The mapping process
This section is devoted to the description of the mapping. It essentially was a labeling process
through which each rule was linked with one or more techniques and their related tactics. Such a
process was carried out on an Excel file provided by the company, where each row corresponded to
a detection to be mapped. A new column for each row was added on the file to host the findings of
this labeling process (i.e. the techniques and the related tactics associated with the detection). The
MITRE ATT&CK framework was exploited to get this task done.
The analysis to get the mapping done can be outlined as follows.
● Analysis of the SPL rule to understand the semantics.
● Searching on the MITRE official website to find a correspondence between the behavior
described by the rule and one or more techniques.
● Writing down the findings on the Excel.
Such a workflow has been iteratively carried out by the thesis author for each detection to be
mapped.
Once a technique related to a specific rule was found, it was relatively handy to find the associated
tactics since the framework provides all the possible involved tactical objectives, as Fig. 5 illustrates.
Figure 5: Description of the Valid Accounts MITRE technique with associated tactics [22].
The set of detections was provided by the company in the form of a single-sheet Excel file, resulting
in a total of 37 rows and 4 columns. As we can see in Fig. 6a, each row corresponds to a rule and has
the following fields, that constitute the columns: Use Case, Device Category, Correlation Search and
Rule SPL.

Figure 6a - Excel file containing the rules. Black areas are superposed on those rules without
permission of sharing
The following table has the purpose of clarifying the semantics of the mentioned fields as well as
illustrating their actual values.
Field Meaning Example Values Type
Use Case Specific context in
which the detection is
applied
Email, Access, Account
Management, Network,
Audit
Enumerated
Device Category Device or application
generating the logs
involved in the
detection
Office 365, Windows
AD, Azure AD, Firewall,
Proxy
Enumerated
Correlation Search Short name or title
assigned to the
detection.
High Volume Email
Activity to Non-
corporate Domains by
User, Excessive Failed
Logins, Possible
Kerberoasting
Free text
Rule SPL Rule written in SPL
language
See figure 6a above or
‘Examples of Rules’
subsection
SPL language
Table 1: Semantics of the fields listed in the aforementioned sheet file
It should be noted that the fieldname Correlation Search is not consistent with the definitions
provided at the beginning of this document (Introduction section). Such a term is used also for
those rules that do not correlate events. This is due to a deliberate choice of the analysts at

Security Reply, as the terms Correlation Rule or Correlation Search are colloquially used within the
organization to denote all the rules, irrespective of whether an actual correlation among events is
performed or not.
The table shows that the provided rules cover various use cases and are related to different device
categories. It is worth mentioning that the structure of this Excel file (i.e. fields, values, number of
rules to be included) has been designed by Reply's security analysts according to their internal
procedures, independently of the MITRE ATT&CK. Indeed, this was exactly the purpose of the
mapping process, that is linking the rules with tactics and techniques of the framework.
In practice, a new field called “Mapping Mitre” was added to the Excel file, devoted to host the tactic
and technique codes, as Fig. 6b shows. Tactics and techniques are coded by MITRE, respectively, as
follows: TA00d{2} and Td{4} (‘ d ’ represents a digit in regular expressions, with the number
between brackets being their count).
Figure 6b: Portion of the Excel file after performing the mapping.
On one hand, the behavior of some detections was exactly mirrored by a technique within the
framework: Kerberoasting [26], Clear Windows Event Logs [27], High Number of MFA challenges for
the same user [28] and Email Forwarding Rule [31] constitute examples of this kind. In such cases,
assigning a technique (and the related tactics) was quite a straightforward action. On the other hand,
some detections depicted slightly more complex scenarios, in the sense that one single technique
was not enough to accurately reproduce them.
To better explain this concept, the detection having “Access: Short-lived Account Detected” as
Correlation Search can be considered. This correlation rule, listed among the ones to be mapped, is
related to access monitoring. It has the aim of detecting the creation and deletion of short-lived
accounts. The identified MITRE technique for the creation part is Valid Accounts [22], listed under
the Persistence tactic [35]. For the deletion part, it was chosen the sub-technique Clear Persistence
[32], belonging to the Indicator Removal [33] technique, listed under the Defense Evasion [34] tactic.
This example highlights the non-atomic nature of rules, in general. It means that use cases observed
in enterprise scenarios are the composition of more atomic behaviors, rather than just one.

Exceptional case during the mapping process
One single instance among the detections was handled differently with respect to the others. Such
an exception consists of a rule designed to identify a malware infecting more than 10 destinations,
with ‘destinations’ referring to any compromised hosts or devices.
No further information regarding the nature of the malware was provided, except that it has a
unique identifier called ‘signature’ that enables the rule to distinguish among different malwares.
Such a detection operates by scanning a so-called datamodel, a sort of repository that stores details
of previously analyzed data. No information was available about the authors of such a datamodel
either.
Due to the lack of details about the types of involved malware and the datamodel itself, it was
decided not to associate this detection with any specific technique within the MITRE ATT&CK
framework.
It should also be noted that in principle each ATT&CK tactical objective can be accomplished by
means of a malware, which is a further reason for considering such a rule too generic.
Examples of rules
Premise
Due to the confidential nature of the detections, it was chosen by the company to not make the
Excel file public. Nevertheless, a few examples of simple rules analyzed for this project are hereby
presented and explained, to give a better idea of how they are structured. Such rules were approved
for sharing, ensuring that confidentiality is maintained.
Windows Logs Event Clearing
index=wineventlog (source="*WinEventLog:Security" AND (EventCode=1102 OR
EventCode=1100)) OR ((source="*WinEventLog:System") AND EventCode=104)
| stats count by _time EventCode sourcetype host
| rename host as orig_host, EventCode as event_code
This rule aims to detect the clearing of security or system logs in Windows environments, as well as
the shutdown of the Event Log Service.
Such events are identified by the following codes: 1102 (Windows Security Log is cleared), 104
(clearing of a system log file) and 1100 (Windows Event Log Service is shut down).
Clearing the logs or disabling the Event Log Service could indicate an attempt to hide unauthorized
actions. Therefore, it can be attributed to the Defense Evasion [34] tactic, that as previously said
describes what attackers do to avoid detection throughout their compromise. The associated
technique is Clear Windows Event Logs [27].

Figure 7: Possible output of the Windows Logs Event Clearing query (grouped so that events with
the same code are together) with Splunk Enterprise.
Figure 8: Security log - code 1102 – in its raw visualization displayed by Splunk. Blurred with Canva
[30]

Figure 9: System log - code 104 – viewed within the Windows Event Viewer.
Possible Kerberoasting
index="*_oswinsec" EventCode=4769 Error_Code=0x0 Ticket_Encryption_Type="0x17"
Ticket_Options IN("0x40810000", "0x40800000", "0x40810010")
service_name="secadmin"
| stats count as "Count events", values(index) as "index", values(host) as "host",
values(dest) as "dest", values(user) as "user", values(ComputerName) as
"computer_name" by log_region, log_country, src
Kerberos is an authentication protocol commonly used in network environments. In this context, an
authenticated user is granted a so-called service ticket, a data structure to be exhibited to the server
that provides the service of interest. This data structure is encrypted with a key derived from a
password.
Because of the over-privilege problem, meaning that a server administrator has more access rights
than supposed, the ability to steal such a key implies risks: an attacker can potentially take control
not only of the server being targeted, but also of other servers, along with the possibility of
modifying access rights of users within the network, eventually implying further privilege escalation.
Therefore, on one hand it is crucial that passwords are chosen properly, on the other that the
cryptography around tickets is robust.

Kerberoasting attacks [40] consist of obtaining a large number of service tickets from the various
servers within the organization, in order to obtain guessing material to get their passwords.
In this case, the detection aims to identify Kerberoasting on a single specific service of interest,
named “secadmin”.
This rule searches across different security logs events whose code is 4769, indicating that a Kerberos
service ticket was requested [36] with no errors (0x0).
The specific Ticket Encryption being searched is the 0x17, known as RC4 [37]. Such an algorithm,
also used in the past for TLS client-server connection establishments, is known to have a variety of
cryptographic weaknesses. For this reason, the IETF (Internet Engineering Task Force), prohibited its
usage by issuing a proper RFC in 2015 [38]; in response to this, Windows started employing AES
encryption for Kerberos. A weak encryption algorithm accelerates the rate (attempts per unit time)
at which a guessing attack is executed.
The ticket options are encoded in flags under the Additional Information field of the event properties
[Fig. 10], having the following meanings [36]
● Forwardable, renewable, canonicalizable (0x40810000)
● Forwardable, renewable (0x40800000)
● Forwardable, renewable, canonicalizable, renewable ok (0x40810010)
The detection is looking for a ticket having one set of options among these three just mentioned. In
Kerberos semantics, Forwardable denotes that a ticket can be sent to another host, thus allowing
the log-in from remote as though the user was logged locally [44]; Renewable indicates that a ticket’s
lifetime can be extended after its expiration, without the need of inserting the password again [44];
Removable-ok means that the client agrees to receive a renewable ticket if the KDC is not able to
provide it with one “sufficiently long” lifetime [36]. The KDC can be thought of as the main server
entity of Kerberos, in charge of both the authentication and authorization services. Finally,
Canonicalize is an option that allows the client to request the KDC to use the actual service names
and not alias [36].
A successful Kerberoasting allows the attacker to impersonate a server. This implies gaining the
ability to receive service tickets from users. If such a ticket is forwardable, the Kerberos protocol
allows its owner - in this case malicious - to request services from other servers with respect to the
one for which the ticket was initially granted, without involving the authentication step.
Since the renewability extends the ticket’s lifetime, it provides its owner with more time to benefit
from the services offered by servers of that network environment without authenticating. According
to MITRE’s jargon, impersonating a server and a user are respectively examples of Privilege
Escalation [45] and Lateral Movement [46] tactics. The ability to gain additional time of permanence
within the network environment is an example of Persistence [35].

Figure 10: Properties of the event 4769 [36]
Studying this rule shows that the mapping process was not simply consisting of finding a match with
the ATT&CK techniques, filling the Excel file and proceeding with the next detection; on the contrary,
it often required a deeper understanding of the reason why a certain SPL query has been written in
a certain way. Most of the efforts for getting the thesis work done were aimed at acquiring sufficient
knowledge of the SPL syntax, which was new, as well as understanding the semantics of each rule
under examination.

MITRE Coverage Assessment
Data explanation and SPL query
This section describes how the MITRE ATT&CK coverage assessment was obtained. From a high-level
point of view, such a procedure consists of an execution of a query that takes as inputs the whole
ATT&CK matrix and the set of previously mapped detections - both in the form of csv files - and
provides as output the MITRE ATT&CK coverage assessment. The first file is needed to know which
and how many techniques are listed by the framework under each tactic, the second one to know
which and how many techniques (and related tactics) are associated with a rule. The result is the
MITRE ATT&CK coverage for each tactic, that is the percentage of the techniques that have an
associated detection.
Before analyzing the query for the MITRE ATT&CK coverage assessment, it is necessary to describe
more in detail the two aforementioned files. Each of them is in csv format and was obtained from
the conversion from xlsx to csv done through Google Sheets.
The first one contains as said the whole ATT&CK matrix, characterized by fields such as Tactic,
Technique, TacticCode, TechniqueCode and Coverage, counting 234 entries (one for each technique).
The first two fields are free-text and contain the name of the tactic and the technique, while the
following two are their respective codes having the already mentioned format TA00d{2} and Td{4}.
The last one is a boolean field whose purpose is distinguishing between covered and uncovered
techniques. Fig. 11 shows a portion of this file.
Figure 11: Fragment of the first input file used for determining the coverage assessment
This file originated from the official MITRE ATT&CK navigator [41], which offers the download of the
ATT&CK matrix as a sheet file. However, an additional work had to be performed on it, because such
a data structure was not aligned with the latest version of the framework.
More in detail, the Reconnaissance [49] and Resource Development [50] tactics were not present,
and so the associated techniques. In addition, some tactics were lacking newly added techniques.
For instance, Defense Evasion had 37 techniques listed under it, instead of the updated count of 43.
Therefore, taking the official website [3] as reference for the latest version being, these gaps were
manually filled by the thesis author. The Coverage field – described above - has been manually added
by the author to the Excel file as well.
The second file derives from the previously performed mapping: it contains the rules along with the
encoded MITRE technique/tactic association, (shown in Fig. 6b the Mapping process section).
The query, developed from scratch from the thesis author, is reported below.

| inputlookup Detection_Coverage_HI.csv
| stats count as total_techniques by Tactic, TacticCode
| join type=left TacticCode
[| inputlookup Real_Mapping_Finale.csv
| search MappingMitre="*TA00*"
| rex field=MappingMitre max_match=0
"(?<TT>((?<TacticCode>((TA00dd)))((?<Technique>(Td{4}))))"
| mvexpand TT | where len(TT) > 0 | dedup TT
| rex field=TT "(?<TacticCode>TA00dd)"
| stats count as detected_techniques by TacticCode ]
| eval detected_techniques = coalesce(detected_techniques, 0)
| table Tactic, TacticCode, total_techniques, detected_techniques
| eval tactic_coverage_percentage = round((detected_techniques /
total_techniques) * 100, 2)
| table TacticCode, Tactic, detected_techniques, total_techniques,
tactic_coverage_percentage
Interface
Describing what is carried out by the query is quite straightforward: given a set of detections mapped
according to the MITRE ATT&CK framework, it provides the coverage percentage for each tactic.
Its interface, that is how it can be used, is very easy to describe as well: it is enough to copy and
paste it within any Splunk environment, provided that the two sheet files properly arranged have
been previously loaded as lookup tables within the platform.
A lookup table is a data structure typically used to complement the searches related to other
analyzed events. For this project however, such tables did constitute the only input source, as Splunk
was used to perform data analysis rather than inspections of events occurring in a network
environment.
The file names can be arbitrarily chosen at the moment of the upload; these ones have then to be
matched in the part of code involving the inputlookup table.
Implementation
This section is devoted to the description of how the query internally works. Such a description
breaks it down into 3 parts, to simplify their understanding. What is meant by ‘first’, ‘second’ and
‘third’ part is clarified by the SPL syntax that appears in the search bar under the New Search label
in the corresponding figures. Essentially, the first and the third parts are respectively those portions
of the query before and after the join command, while the second is the one involving the join
statement itself.
The first part counts the total techniques listed under each tactic. The output of this sub-search can
be viewed in the following picture, Fig. 12.

Figure 12: Partial output for the first part of the query
The second part of the query counts the detected techniques for each tactic (i.e., how many
techniques are covered by one or more detection).
It works by extracting the tactic-technique association by means of a simple regex. A regex is also
used to identify the tactic code under which the detected techniques are collected. Fig. 13 shows
the findings of this search fragment.

Figure 13: Partial output for the second part of the query
The join command unifies the two partial results to create a unique derived table. It enhances the
previously obtained table [Fig. 12] by appending the count of detected techniques [Fig. 13] to each
tactic. Fig. 14 illustrates this combined output.

Figure 14: Partial output of the query after the join command
The last part finally computes the coverage percentage for each tactic, determined by the ratio
between the techniques with an associated detection and the available ones.
The order in which the two lookup tables are queried is not random: indeed, by first extracting the
detected techniques and then applying the join command to enrich the output table with the total
techniques, just 13 rows would appear in the final output: the Resource Development [50] tactic
would be omitted, as it counts zero detected techniques. However, it is of critical importance for the
MITRE ATT&CK coverage assessment to highlight what tactics are completely unaddressed, which is
why the sequence of operations is as such.

Figure 15: Final output of the query: MITRE Coverage
Discussion on the obtained coverage
As said earlier, an alternative method can be used for conducting this analysis, besides employing
the Excel file. It consisted of implementing each rule in Splunk (Enterprise Security), tagging it with
the appropriate ATT&CK label and carrying out the coverage analysis based on these tags.
However, the proposed approach is cost-free and can be used regardless of the specific Splunk
license in use, in line with the project’s constraints. Moreover, its generic nature implies that any
appropriately formatted set of mapped rules within a csv can undergo this analysis, thus yielding the
illustrated MITRE ATT&CK Coverage output.
This coverage can aid organizations in understanding their security posture and any gaps to be filled.
For instance, supposing to be using this set of rules as a baseline for setting up the cyber defense of
an organization, useful hints come up:
- Tactics that are entirely unaddressed (e.g. Resource Development [50]) or barely (e.g.
Collection [51]) may be prioritized.
- 6 tactics out of 14 exhibit less than 20% coverage.
- 2 tactics, Credential Access and Command and Control [53], exhibit a relatively high coverage,
41% and 35% respectively.
- Defense Evasion, in spite of being the tactic with the highest absolute number of covered
techniques (8), has a modest coverage: 18.60%.
Of course, each organization prioritizes defenses differently, based on their specific needs and on
the potential impact that security gaps may imply.
It is important to note that the set of rules employed in this project is not exhaustive. The limited
number of detections was determined by the project timeline, with the focus on proposing a cost-
free methodology rather than providing a real-world security posture analysis. As a consequence,

while the findings of the query output are plausible, they do not reflect actual potential
vulnerabilities and coverage gaps of any existing company. It is just an educational illustration.
Future works could involve expanding the set of detections, to provide a more complete view of the
framework’s coverage and conduct more relevant analyses and actions.
An alternative illustration
A visual representation of the obtained coverage could be obtained by means of a free Splunk add-
on called Mitre Attack Heatmap [42]. This extension allows to display all the techniques listed by the
framework in the form of the MITRE ATT&CK matrix.
For this purpose, a simple query was written by following the instructions on the tool’s
documentation. Such a query has the effect of coloring the techniques having an associated
detection. The first file used for evaluating the MITRE ATT&CK coverage, mentioned in the Data
Explanation and SPL Query section [Fig. 11], was used as input. The boolean field ‘Coverage’ is used
to discriminate between covered and uncovered techniques.
The simple query is reported below.
| inputlookup Detection_Coverage_HI.csv
| search Coverage = "y"
| stats count AS "Detection Count" by TechniqueCode
| table TechniqueCode "Detection Count"

Figure 16: Alternative visualization of the MITRE Coverage (cropped for a more compact
representation)
It is worth mentioning that such a tool also allows a different color semantics, making darker and
brighter, respectively, those techniques with a higher and lower number of associated detections. In
the case of the rules used for this project, the most covered technique, that is Valid Accounts (with
code T1078), shows a count of 4, meaning that it is addressed by 4 different detections.
By properly tuning the settings of the tool and establishing an upper bound of 4 (Fig. 18), a heatmap
with color semantics can be produced (Fig. 19).
Figure 17: Color settings for the MITRE ATT&CK Heatmap Splunk add-on
Fig 18: Heatmap with color semantics shown in the previous figure enabled

However, real cases imply the usage of a much wider set of detections with respect to the one in use
for this project. Therefore, the output representation should be more likely as shown below (Fig.
19).
Figure 19: MITRE ATT&CK Heatmap [43]
In this case, taken from the Heatmap for Splunk web page [43], semantics of color assigns grey for
the unaddressed techniques, using hot and cold colors techniques which are respectively poorly and
highly covered.
By hovering a certain technique with the mouse, the link to the MITRE ATT&CK official website
containing its description is provided to the user (Fig. 20).
Figure 20: Detail of a technique provided by the Heatmap for Splunk add-on

Conclusions
The goal of the project was to use a reference cybersecurity framework, specifically the MITRE
ATT&CK, to enhance a corporate SIEM system. The ambition consisted of identifying tactics and
techniques to associate with each rule, thus allowing analysts to get a more comprehensive
understanding regarding the security incidents. This involved mapping existing detections that were
unmapped, as well as the development of a query to evaluate the MITRE coverage.
Part of this project was supposed to be devoted to testing new detections by exploiting Splunk Attack
Range (see the Appendix for more details). It was not carried on due to cost constraints. This is not
necessarily a negative result: it implies that now the company has a narrower range of tools to test
for further explorative analyses.
The mapping process required the analysis of 37 rules. All of them have been successfully mapped
to ATT&CK’s tactics and techniques, except for a single detection associated with tactics only.
Due to the lack of expertise of the author and the absence of previous knowledge regarding the
Splunk Processing Language and the rules, the mapping part and the subsequent development of
the query were the most effort and time-expensive phases of the whole project. Also the initial
theoretical study regarding the literature was relatively demanding.
It is important to point out that the author’s contribution was supposed to be the mapping of rules,
rather than the development of new detections or the refinement of existing ones. As a result, the
Incident Response Team at Security Reply team can leverage this project’s outcome for security
posture evaluation, so to be then able to take actions accordingly.
I found a significant level of personal satisfaction from this work. This experience has improved my
technical skillset with theoretical and practical knowledge about the current standard reference
framework used in cybersecurity, the MITRE ATT&CK. In addition to it, I gained hands-on experience
with Splunk and SPL’s basics. Of course, this still leaves me far from being an expert of these topics;
mastering Splunk (and more in general SIEM systems) and having a deep extensive knowledge of
techniques and tactics of ATT&CK require years of on-field experience. However, this project helped
me scratch the surface of understanding what happens behind the scenes of the detection of
security incidents.
Another important understanding is that, while ideally businesses would have an infinite budget to
be allocated for cybersecurity, the reality is far different. Not all companies allocate resources
devoted to their defense, and for the ones that do as such, it is too optimistic to think that they have
the resources to fill all their cybersecurity needs with no gaps. In the real world, financial constraints
(either lack of money or a bad allocation of it) are a common challenge.
Finally, I would like to express my gratitude to Lorenzo Del Sordo, the co-supervisor of this thesis,
who taught me a lot and clarified my doubts throughout the process, and to Alberto Bartoli, the
supervisor of the whole work, who was constantly available and ready to help whenever I was facing
technical and non-technical problems.

Appendix
Feasibility analysis of Splunk Attack Range
Part of this thesis work was dedicated to the exploration of a promising approach to test new
detections against simulated attacks.
The tool to be examined, proposed by the company, is called Splunk Attack Range [7], [8], an open-
source project developed by the Splunk Threat Research Team. It allows users to build a controlled
environment where it is possible to perform attack simulations based on the MITRE framework. Its
goal is testing the detection capabilities available in the Splunk Security Content GitHub [9]. The set
of attacks is collected within a library called Atomic Red Team [10]; every attack is related to a MITRE
technique.
The initial task was supposed to be the reproduction of known scenarios, to understand the
effectiveness of the detections in use, that is the ability to generate an alert regarding the simulated
attack, along with information about the associated tactic and technique.
To carry out such an analysis, a dive into the Splunk Enterprise Security official documentation [5],
[6] was required, as such a tool included an instance of Splunk ES.
In its simplest configuration, the following components are used to build up the Splunk Attack Range
architecture and resemble an enterprise environment:
- an ES Splunk instance, accessible through a Web UI, whose aim is collecting and analyzing
simulation data;
- A workstation, a server, and a domain controller windows-based machines as potential targets of
attacks. All of them are pre-configured with a software component called Splunk Universal
Forwarder, whose job is sending the logs collected on each machine to Splunk.
In this context, the Atomic Read Team scripts are executed directly on the target machine, with the
purpose of generating realistic logs that are used to refine the detection capabilities.
This simulation environment is hosted in the cloud, implying that the machines in use are not
physical devices, but virtual instances. For this purpose, Microsoft Azure or Amazon Web Services
(AWS) can be used.
A free-tier account of amazon AWS was created to use Splunk Attack Range. The simulation
environment was successfully set up; however, the granted free resources had soon finished, and
the cost for keeping the entire environment alive and working was considered excessively high by
the company. For this reason, it was decided to not furtherly explore this branch. This allowed the
simulation of just a few attacks, much less with respect to the initial intentions.
By looking at the official page of Splunk Attack Range, there was no indication about its costs.
However, a deeper look into the deprecated wiki shows that the authors estimated a cost of about
230 dollars per month [Fig.21], with the hypothesis of using the environment 3 hours per week [12].

Figure 21: Cost estimation for the Splunk Attack Range tool

Bibliography
[1] Orca Security. "Understanding the MITRE ATT&CK Framework." Orca Security Blog, https://orca.security/resources/blog/mitre-
attck-framework/, accessed on November 28, 2023.
[2] Bartoli, Alberto. "(CYBERSEC 2) - Attacks – 139.pdf" Computer Networks II and Principles of Cybersecurity. University of Trieste,
April 21, 2022.
[3] MITRE ATT&CK, official website. https://attack.mitre.org/ first accessed on July 03, 2023.
[4] Mitre Corporation, wikipedia website, https://en.wikipedia.org/wiki/Mitre_Corporation
[5] Splunk Enterprise Security, official website. https://www.splunk.com/en_us/products/enterprise-security.html first accessed in
July 2023.
[6] Installation of Splunk Enterprise Security, official website. https://docs.splunk.com/Documentation/ES/latest/Install/Overview,
first accessed in July 2023.
[7] Splunk Attack Range, introduction and installation guide, official website. https://www.splunk.com/en_us/blog/security/attack-
range-v3-0.html, first accessed in July 2023.
[8] Splunk Attack Range, GitHub repository, https://github.com/splunk/attack_range, first accessed in July 2023.
[9] Splunk Security Content, GitHub repository, https://github.com/splunk/security_content/, first accessed in July 2023.
[10] Atomic Red Team, GitHub repository, https://github.com/redcanaryco/atomic-red-team, first accessed in July 2023.
[11] Atomic Red Team cost-estimates, GitHub wiki, https://github.com/splunk/attack_range/wiki/Cost-Estimates#cost-estimates,
first accessed in July 2023.
[12] Yadav, T., Rao, A.M. (2015). Technical Aspects of Cyber Kill Chain. In: Abawajy, J., Mukherjea, S., Thampi, S., Ruiz-Martínez, A.
(eds) Security in Computing and Communications. SSCC 2015. Communications in Computer and Information Science, vol 536.
Springer, Cham. https://doi.org/10.1007/978-3-319-22915-7_40
[13]Cyber Kill Chain figure, downloaded from the official website: https://www.lockheedmartin.com/en-
us/capabilities/cyber/cyber-kill-chain.html.
[14] Roy, S., Panaousis, E., Noakes, C., Laszka, A., Panda, S., & Loukas, G. (2023). SoK: The MITRE ATT&CK Framework in Research
and Practice. arXiv preprint arXiv:2304.07411.
[15] S. B. Son, S. Park, H. Lee, Y. Kim, D. Kim and J. Kim, "Introduction to MITRE ATT&CK: Concepts and Use Cases," 2023
International Conference on Information Networking (ICOIN), Bangkok, Thailand, 2023, pp. 158-161, doi:
10.1109/ICOIN56518.2023.10048930.
[16] CALDERA official website, https://caldera.mitre.org/
[17] CALDERA, GitHub repository, https://github.com/mitre/caldera
[18] R. Kwon, T. Ashley, J. Castleberry, P. Mckenzie and S. N. Gupta Gourisetti, "Cyber Threat Dictionary Using MITRE ATT&CK Matrix
and NIST Cybersecurity Framework Mapping," 2020 Resilience Week (RWS), Salt Lake City, UT, USA, 2020, pp. 106-112, doi:
10.1109/RWS50334.2020.9241271.
[19] S. Bagui, D. Mink, S. Bagui, T. Ghosh, T. McElroy, E. Paredes,N. Khasnavis, and R. Plenkers, “Detecting reconnaissance and
discovery tactics from the MITRE ATT&CK framework in Zeek Conn Logs
using Spark’s machine learning in the big data framework,” Sensors,
vol. 22, no. 20, p. 7999, 2022

[20] I. K. Sahu and M. J. Nene, “Model for IaaS security model: MISP
framework,” in 2021 International Conference on Intelligent Technologies (CONIT). IEEE, 2021
[21] Tarnowski, I., 2017. How to use cyber kill chain model to build cybersecurity?. European Journal of Higher Education IT.
[22] MITRE ATT&CK, official website, “Valid Accounts” technique, https://attack.mitre.org/techniques/T1078/
[23] O. Podzins and A. Romanovs, "Why SIEM is Irreplaceable in a Secure IT Environment?," 2019 Open Conference of Electrical,
Electronic and Information Sciences (eStream), Vilnius, Lithuania, 2019, pp. 1-5, doi: 10.1109/eStream.2019.8732173.
[24] Lockheed Martin, official website, https://www.lockheedmartin.com/
[25] Splunk Official Website, CKC vs MITRE https://www.splunk.com/en_us/blog/learn/cyber-kill-
chains.html#:~:text=A%20cyber%20kill%20chain's%20purpose,Ransomware, accessed in December 2023.
[26] MITRE official website, Kerberoasting technique, https://attack.mitre.org/techniques/T1558/003/
[27] MITRE official website, Clear Windows Event Logs, https://attack.mitre.org/techniques/T1070/001/
[28] MITRE official website, Multi-Factor Authentication Request Generation, https://attack.mitre.org/techniques/T1621/
[29] Splunk official documentation, Search Tutorial,
https://docs.splunk.com/Documentation/Splunk/9.1.2/SearchTutorial/WelcometotheSearchTutorial
[30] Canva, official website, used to blur the correlation rules in the image of the Excel table. https://www.canva.com/
[31] MITRE official website, Email Forwarding Rule, https://attack.mitre.org/techniques/T1114/003/
[32] MITRE official website, Indicator Removal (sub-technique): Clear Persistence, https://attack.mitre.org/techniques/T1070/009/
[33] MITRE official website, Indicator Removal technique, https://attack.mitre.org/techniques/T1070/
[34] MITRE official website, Defense Evasion tactic, https://attack.mitre.org/tactics/TA0005/
[35] MITRE official website, Persistence tactic, https://attack.mitre.org/tactics/TA0003/
[36] Microsoft Learn, Kerberos Service Ticket Event Description, https://learn.microsoft.com/it-it/windows/security/threat-
protection/auditing/event-4769, accessed in December 2023
[37] Biosidmartin.com, What is ticket encryption type0x17? https://biosidmartin.com/what-is-ticket-encryption-type-0x17/,
accessed in December 2023.
[38] Datatracker.ietf.org, Request For Comments 7465 for prohibiting RC4 https://datatracker.ietf.org/doc/html/rfc7465
[39] Splunk Blog – What splunk does - https://www.splunk.com/en_us/blog/learn/what-splunk-does.html
[40] SentinelOne, Kerberoasting Attack, https://www.sentinelone.com/cybersecurity-101/what-is-kerberoasting-attack, accessed in
December 2023.
[41] ATT&CK Navigator, official website, https://mitremap.splunkresearch.com/
[42] MITRE ATT&CK Heatmap, GitHub repository, https://github.com/alatif113/mitre_attck_heatmap
[43] MITRE ATT&CK Heatmap for Splunk, add-on page, https://splunkbase.splunk.com/app/5742
[44] Kerberos ticket properties, MIT education website, https://web.mit.edu/kerberos/krb5-latest/doc/user/tkt_mgmt.html,
accessed in January 2024
[45] MITRE official website, Privilege Escalation tactic, https://attack.mitre.org/tactics/TA0004/

[46] MITRE official website, Lateral Movement tactic, https://attack.mitre.org/tactics/TA0008/
[47] Lantern Splunk website, Assessing and expanding MITRE ATT&CK coverage in Splunk ES,
https://lantern.splunk.com/?title=Security%2FUCE%2FPrioritized_Actions%2FCyber_frameworks%2FAssessing_and_expanding_MIT
RE_ATT%26CK_coverage_in_Splunk_Enterprise_Security
[48] MITRE official website, Discovery tactic, https://attack.mitre.org/tactics/TA0007/
[49] MITRE official website, Reconnaissance tactic, https://attack.mitre.org/tactics/TA0043/
[50] MITRE official website, Resource Development tactic, https://attack.mitre.org/tactics/TA0042/
[51] MITRE official website, Collection tactic, https://attack.mitre.org/tactics/TA0009/
[52] MITRE official website, Credential Access tactic, https://attack.mitre.org/tactics/TA0006/
[53] MITRE official website, Command and Control tactic, https://attack.mitre.org/tactics/TA0011/
[54] Hutchins, Eric M., Michael J. Cloppert, and Rohan M. Amin. "Intelligence-driven computer network defense informed by
analysis of adversary campaigns and intrusion kill chains." Leading Issues in Information Warfare & Security Research 1.1 (2011): 80.
[55] Morning Consult, IBM, Global Security Operations Center Study Results, 2023 -
https://www.ibm.com/downloads/cas/5AEDAOJN

Mapping Security Information and Event Management (SIEM) Rules to Tactics and Techniques of the MITRE ATT&CK Framework

Recommended

Recommended

More Related Content

Similar to Mapping Security Information and Event Management (SIEM) Rules to Tactics and Techniques of the MITRE ATT&CK Framework

Similar to Mapping Security Information and Event Management (SIEM) Rules to Tactics and Techniques of the MITRE ATT&CK Framework (20)

Recently uploaded

Recently uploaded (20)

Mapping Security Information and Event Management (SIEM) Rules to Tactics and Techniques of the MITRE ATT&CK Framework