Active Directory Kerberoasting Attack: Monitoring and Detection

Techniques

Lukáš Kotlaba, Simona Buchovecká and Róbert Lórencz

Department of Information Security, Faculty of Information Technology, Czech Technical University in Prague,
Czech Republic
{kotlaluk, simona.buchovecka, lorencz}@fit.cvut.cz

Keywords: MS Active Directory, Kerberos Security, Kerberoasting, Cyber Security, Cyber Attacks.

Abstract: The paper focus is the detection of Kerberoasting attack in Active Directory environment. The purpose of the
attack is to extract service accounts’ passwords without need for any special user access rights or privilege
escalation, which makes it suitable for initial phases of network compromise and further pivot for more
interesting accounts. The main goal of the paper is to discuss the monitoring possibilities, setting up detection
rules built on top of native Active Directory auditing capabilities, including possible ways to minimize false
positive alerts.

1 INTRODUCTION ers and cybercriminals. It is crucial to understand how

important role Active Directory plays in an enterprise
Active Directory (AD) is a proprietary domain, and what kind of data it stores. Thus, it is not
implementation of a directory service for Microsoft’s surprising that AD is often a target of attacks. Indeed,
Network Operating System (NOS). NOS is the term AD does not even have to be the target itself, as it may
used to describe a networked environment in which only serve as a bare tool providing a path for
various types of resources, such as user, group, and compromising more interesting systems in the
computer accounts, are stored in a central repository. domain, as discussed in (Kotlaba, 2019).
This repository, called Active Directory, contains The paper is focused on one such attack –
network, application, or NOS information that is Kerberoasting – the purpose of which is to extract
controlled by administrators and accessible to end service accounts’ passwords without need for any
users. The directory service that provides access to special user access rights or privilege escalation.
this repository is called Active Directory Domain Discussion on the techniques for attack detection in
Services (AD DS) (Desmond et. al. 2013). (almost) real time is presented, including the
The AD is widely used as the core part of the monitoring scenarios and tuning options for
whole network infrastructure; as a central repository minimizing potential false positive alerts.
for information about objects that reside on a The paper is structured as follows - Section 2
company network, such as users, groups, computers, contains background information on authentication
printers, applications, and files. The objects have process in Active Directory environment, with focus
numerous attributes, specific permissions, and on Kerberos protocol. Further, details of the
relations. AD stores all this data in a hierarchical Kerberoasting attack itself are discussed. Section 3
organizational structure and provides access to it for presents results of our work – design and
users. implementation of monitoring scenarios for detecting
Microsoft Active Directory is based on the the Kerberoasting attack, including discussion on
LDAPv3 protocol, which is an updated version of efficiency and minimization of false positive alerts.
LDAP, introduced in 1997. The first version of Section 4 concludes the paper.
Microsoft AD was released with Windows 2000 and
has been a part of Windows Server operating systems
(OSs) ever since. (Desmond, 2013, Francis, 2017)
As such, AD is a very attractive target for attack-
2 BACKGROUND protocol being the preferred authentication method in
AD environment.
The Windows OSs require all users to log on to the Windows OSs implement Kerberos version 5
computer with a valid account to access local and authentication protocol, which is specified in RFC
network resources. Authentication is a process of 4120 (Neumann, 2005). Microsoft’s proprietary
verifying the claimed identity of an object; implementation of this protocol adds some
authorization is a process of verifying that the object functionality beyond the RFC specification, such as
has rights to access particular resources. AD is the authorization or optional Privilege Account
default technology for storing identity information on Certificate (PAC) validation (Microsoft, 2019).
domain-joined systems, and therefore it is tied closely Kerberos is the default protocol used within an
to authentication and authorization processes. Active Directory domain. With Kerberos, passwords
Microsoft documentation provides details on key never traverse the network in plaintext or encrypted
concepts (Microsoft, 2016) as follows. formats. Instead, session-specific keys are generated
for use over a short period of time through the use of
2.1 Windows Authentication Overview tickets. The tickets are issued by Kerberos Key
Distribution Center (KDC), which is integrated into a
Users are authenticated to Windows-based computers domain controller (DC) in the Microsoft’s Kerberos
by a logon process. Depending on how the logon implementation. The KDC uses the AD as its security
process occurs, there are several scenarios defined: account database.
 Interactive logon Figure 1 illustrates Kerberos authentication steps
o Local logon (Desmond, 2013 and Metcalf, 2014), which occur
o Remote logon when a user attempts to access a service:
 Network logon 1. To begin the authentication process, an
 Smart card logon AS_REQ message is sent from client to KDC. This
 Biometric logon message proves the user’s identity and is partially
encrypted with a hash of the user’s password
During an interactive logon, a user typically enters computed by the client computer.
credentials in the credentials’ entry dialog box. 2. The DC validates the request and produces a
Alternatives for presenting credentials in the form of Ticket Granting Ticket (TGT). The TGT is sent back
username and password are smart card logon and to the client as AS_REP message. The TGT contains
biometric logon. PAC with information about all the security groups in
Users can perform an interactive logon by using a which the user is a member. It is encrypted and signed
local account or a domain account. Depending on the by the KDC service account (krbtgt). The client
account type, the logon process confirms the user’s caches the TGT in memory.
identification to the security database on the user’s 3. The client sends a TGS_REQ message to the
local computer or to the AD database. A local logon DC to request a service ticket for a specific service.
grants a user permission to access resources on the Rather than providing credentials again, the message
local computer or resources on networked computers. contains the cached TGT obtained in the previous
A domain logon grants a user permission to access step.
local and domain resources. Domain logon requires 4. The DC validates the TGS_REQ and constructs
that both the user and computer have their accounts a Ticket Granting Service (TGS) ticket for the
in AD and the computer is physically connected to the requested service. The TGS ticket, partially encrypted
network. with a hash of the service’s password, is sent back to
A network logon can only be used after user, the client in a TGS_REP message. The client caches
service, or computer authentication has taken place. this ticket in memory for subsequent use when
The network logon process does not use the authenticating directly to the service.
credentials entry dialog boxes; the authentication is 5. The client presents the TGS ticket to the service
typically invisible to the user unless alternative in an AP_REQ message. The service uses it to
credentials have to be provided. Previously authenticate the user. The service might also use the
established credentials are used to confirm identity to user’s access token (contained in the ticket) to
any network service that the user is attempting to perform authorization before allowing access.
access. 6. Optionally, the service can respond with an
Various authentication protocols are used to AP_REQ message for mutual authentication of the
provide network logon functionality, Kerberos service.
 7. Optionally, the service may also send the TGS 2.2 Kerberoasting
ticket to a KDC to validate the PAC to ensure the
user’s group membership presented in the ticket is The Kerberoasting attack was first introduced by Tim
accurate. Medin (Medin, 2014), with the goal to crack
8. If the PAC validation occurs, the KDC informs passwords for remote service accounts completely
the server hosting the specific service about the offline, without sending a single packet to the service,
validation result. and without requiring special or escalated privileges.
Since any authenticated user possessing a valid
TGT may request one or more TGS tickets for any
SPN from a domain controller, this process can be
abused by adversaries in the Kerberoasting technique.
An attacker that controls a user account can request a
service ticket. The ticket may be encrypted with a
weak cipher suite, such as RC4-HMAC-MD5, which
means the service account’s NT password hash is
used to encrypt the service ticket. The attacker then
exports the ticket from memory and attempts to crack
it offline by trying different NT hashes. When the
ticket is successfully opened, the correct service
Figure 1: Kerberos authentication. account password is discovered in plaintext. Cracking
of hashes is usually done on adversary-controlled
Kerberos allows users to access services on the systems with high computational power, outside of
network transparently by simply requesting a service the target network (MITRE, 2018, Metcalf, 2017).
ticket. When clients request service tickets for given
services from a DC, they use identifiers called Service Table 1: Encryption types implemented in Windows.
Principal Names (SPNs). An SPN is stored in AD, in Type Cipher suite name
the servicePrincipalName multivalued attribute. It is 0x1 DES-CBC-CRC
constructed in the form of a service identifier, 0x3 DES-CBC-MD5
0x11 AES128-CTS-HMAC-SHA1-96
followed by the hostname, and optionally, a port 0x12 AES256-CTS-HMAC-SHA1-96
number. The service identifier is a predefined string 0x17 RC4-HMAC-MD5
that the client and server agree on. To enable 0x18 RC4-HMAC-EXP
authentication, Kerberos requires that SPN be
associated with at least one service logon account Table 1 shows implemented encryption types
(Desmond et. al. 2013). used by Kerberos in Windows OSs. Starting from
All the authentication attempts, successful and not Windows Server 2008 and Windows Vista, the suites
successful, are being audited. The event logging containing AES cipher have been set as default,
service records events from various sources and replacing previous default RC4 cipher suites. Also,
stores them in a single collection called Windows cipher suites involving DES cipher have been
Event Log. disabled starting from Windows 7 and Windows
Several categories provided by the security audit Server 2008 R2 (Microsoft, 2017).
policies represent an essential source of information These updates comply with security issues arising
for hunting attacks towards Active Directory. For from RC4 and DES ciphers, as these ciphers are
instance, the categories Account Logon and considered obsolete nowadays. However, Windows
Logon/Logoff track authentication and use of allows enabling these suites via policy setting for
credentials, which is the core element of the attacks. backward compatibility (Microsoft, 2017).
Categories Account Management and DS Access The main reason why Kerberoasting is successful
record changes and replication of the AD schema. is underrated administration of service accounts in
Other categories, such as Detailed Tracking, Object organizations. Many service account passwords are
Tracking, and Privilege Use provide useful often weak, and of the same length as the configured
information that may be related to attack preparation, domain password minimum. Another problem is that
use of hacking tools, or resource access after the service accounts often don’t have passwords set to
successful attack execution. expire. Furthermore, most service accounts are over-
We will utilize the native auditing capabilities to permissioned; they contain rights to access certain
build our detections later on. objects or rights equivalent to Administrator (Metcalf
2017). detections tuning in the end.
The first step of the Kerberoasting attack is For practical testing we used a virtual lab
usually SPN scanning. Querying for registered SPNs environment to simulate an example of a small
enables an attacker to identify all service accounts domain, consisting of one physical machine and five
supporting Kerberos authentication together with virtual machines (VMs). The host computer ran
their role. Checking whether the service accounts Linux OS and was network-connected with the VMs
have the attribute AdminCount equal to "1" identifies to receive logs. The VMs include two servers, one DC
accounts which are members of highly privileged (DC01) and one member server (SERVER2008), and
groups. Attackers use these methods to identify two users’ workstations (WINDOWS7 and
interesting service accounts to focus on (Metcalf, WINDOWS10). The last VM (kali) runs Kali Linux
2017). distribution and serves as a simulation of an external
Kerberoasting and SPN scanning can be attacker having network connectivity to the domain.
performed directly from PowerShell (Metcalf, 2017), Logs from all monitored assets are sent to the physical
or by using various tools. Such tools include machine where they are indexed by a Splunk instance.
PowerShell script Invoke-Kerberoast, which is also The described environment is illustrated in Figure 2.
part of the offensive framework Empire (Schroeder, Splunk is a software product that enables to
2016), or GetUserSPNs module of Impacket, which is search, analyze, and visualize the data gathered from
a collection of Python classes for working with the components of IT infrastructure or business, it
network protocols (SECURAUTH, 2019). takes in data from websites, applications, sensors,
From the nature of Kerberos authentication and devices, etc. (Splunk 2019). We have used Splunk
the fact that usage of services is standard behavior in instance as a central collection point for Active
an AD domain, there is no mechanism of how Directory logs, as well as central monitoring point for
Kerberoasting can be prevented by firewalls or our designed detections – all the presented scenarios
IDS/IPS devices. Furthermore, the obsolete cipher were developed in Splunk Processing Language in
suites are commonly enabled in the environment due form of detection searches from the collected audit
to backward compatibility. This implies the need for data.
monitoring and detection of Kerberoasting attack in For testing the designed scenarios, we used three
the domain. tools to request a service ticket:
 GetUserSPNs module of Impacket
(SECUREAUTH, 2016);
3 PROPOSED MONITORING  Invoke-Kerberoast module of Empire (Schroeder,
2016);
APPROACH  PowerShell commands based on (Metcalf, 2017).
The process of designing the detection rules starts
with defining all related log sources that may contain
relevant data. For events, it is crucial to identify what
information they carry, and under which
circumstances they are logged, or whether they are
generated at all. In many cases, also a trade-off
between the added value and the volume of generated
events has to be taken into consideration. Microsoft’s
documentation of Advanced security audit policy
settings (Microsoft, 2017) and Randy Franklin
Smith’s Log Encyclopedia (Smith, 2006) are the
ultimate reference sources of event descriptions,
logging settings, event occurrences, and other
information related to Windows Event Log.
After a scenario is designed, it is necessary to test
its detection capabilities and evaluate the relevancy of
the returned results. We have tested all proposed
detection rules and evaluated their efficiency from the
perspective of True Positive/False Positive ratio. As
it shows, the naive approach produces a high number
of False Positive alerts, and thus, we focused on the Figure 2: Lab environment.
3.1 Log Sources in the environment, all Kerberos authentication
should use AES cipher suites, and therefore, any
The Kerberoasting technique is targeting Kerberos requests for TGS tickets with lower encryption types
mechanism used to authenticate users who access can be considered suspicious. The detection rule D01
protected network resources. The variety of events - Possible Kerberoasting activity looks for any ticket
which contain useful information for this scenario requests with encryption type constants equal to the
narrows to a single subcategory of Advanced security values of these cipher suites (visible from Table 1).
audit policies: Account Logon\Kerberos Service The snippet of the search is in Listing 1.
Ticket Operations. This policy subcategory should
generate three events: Listing 1: D01 – Possible Kerberoasting activity (snippet).
 4769(S, F) A Kerberos service ticket was source=XmlWinEventLog:Security
requested; EventCode=4769 (TicketEncryptionType=0x1 OR
 4770(S) A Kerberos service ticket was renewed; TicketEncryptionType=0x3 OR
TicketEncryptionType=0x17 OR
 4773(F) A Kerberos service ticket request failed. TicketEncryptionType=0x18)
The Microsoft documentation narrows the choice of |eval Source=if(IpAddress=="::1", Computer,
IpAddress)
events even more. The event 4773 is defined but |table _time, host, Source, TargetUserName,
never invoked, and failure event 4769 is generated ServiceName, TicketEncryptionType
instead. Event 4770 logs every TGS ticket renewal. |sort - _time
However, it has only informational character, and no | ...
security monitoring recommendations exist for it
(Microsoft, 2017). 3.2.2 Suspicious Service Ticket Requests
The event 4769 generates every time KDC gets a
Kerberos TGS ticket request. The event generates The next two detection searches focus on service
only on DCs, however, it is one of the most numerous ticket requests and aim to detect suspicious usage of
events logged (Metcalf, 2017). This event contains services more generally. The rule D02 - Excessive
lots of valuable information, including account, service ticket requests from one source (Listing 2)
service, or network information, encryption type used, triggers if there is a higher amount of different service
and failure code. It is a key element for monitoring requests observed in a short time from a single source.
suspicious activities related to services. This kind of activity is even more suspicious if the
Another type of logs that may be useful for this service names are not related to each other, or if the
scenario, although not so directly, are PowerShell type of requested services is unusual for that
logs. PowerShell Script Block Logging records particular source.
compiled blocks of scripts into event 4104; The search uses events 4769. Service ticket
PowerShell Module Logging records module usage requests for krbtgt service and computer account
into event 4103. service names (those ending with $ character) are
filtered out from the results, as the search focuses
mostly on service accounts that were intentionally
3.2 Detection Scenarios created for specific resources. Subsequent events are
grouped on IpAddress field by the transaction
Kerberoasting technique, as described in the previous
command. The number of services in each transaction
section, involves the use of a valid domain user’s
is calculated and filtered to display only results where
authentication ticket (TGT) to request one or several
the number is higher than the one specified in the
service tickets using their SPNs. Since the goal of an
condition. The number constant and time span used
attacker is to crack the service ticket offline, tickets
in the condition represent a variable and have to be
encrypted with weak cipher suites are preferred.
adjusted to the needs of the particular environment.
Sean Metcalf did some research and published
The values presented in the search snippet were used
several articles on this topic, which name elements
in the lab environment.
suitable for detection of Kerberoasting. We were
inspired by ideas published in these articles (Metcalf,
Listing 2: D02 – Excessive service ticket requests from one
2017) while designing the detection scenarios. source (snippet).
3.2.1 Detecting Kerberoasting via Event source=XmlWinEventLog:Security
EventCode=4769 ServiceName != krbtgt
4769 |regex ServiceName != "\$$"
|transaction IpAddress maxpause=5m
Unless there are incompatible or legacy systems used maxevents=-1
|eval services=mvcount(ServiceName) attribute set, it could be a member of seemingly
|where services > 5
| ...
privileged groups to lower potential suspicions of an
attacker. Listing 4 shows the detection rule D04 -
Detecting Kerberoasting with a honeypot.
Listing 3: D03 – Suspicious external service ticket requests
(snippet).
Listing 4: D04 – Detecting Kerberoasting with a honeypot
source=XmlWinEventLog:Security (snippet).
EventCode=4769 IpPort > 0 (IpPort < 1024 OR
(NOT (IpAddress=10.0.0.0/8 OR source=XmlWinEventLog:Security
IpAddress=172.16.0.0/12 OR EventCode=4769 ServiceName=Honeypot01
IpAddress=192.168.0.0/16 OR |eval Source=if(IpAddress=="::1", Computer,
IpAddress=127.0.0.1 OR IpAddress=::1))) IpAddress)
| ... |table _time, host, Source, TargetUserName,
ServiceName, TicketEncryptionType
Another search, D03 - Suspicious external service |sort - _time
| ...
ticket requests, follows a security recommendation
described by Microsoft in its documentation for the 3.2.4 Detecting Kerberoasting via
event 4769 (Microsoft, 2017). The search focuses on PowerShell
network information provided in the event. It
monitors usage of well-known ports or any events Kerberoasting activity can be carried through
where the IP address is not from the private IP ranges, PowerShell on a workstation controlled by an attacker.
which are signs of an outbound connection. The The search D05 – Detecting Kerberoasting via
Listing 3. shows the detection logic used. PowerShell uses features of PowerShell logging and
The range of IP addresses can be narrowed to only its goal is to catch SPN scanning activity or successful
those used in the environment. If there is a scenario acquisition of the service ticket hash.
where the monitored ports or IP addresses are used by The search looks for PowerShell events 4103 and
legitimate services, the values can be whitelisted by 4104 and performs a full-text search in them, looking
modifying the detection condition. for strings containing names of service accounts.
Transactions are created for all subsequent
3.2.3 Detecting Kerberoasting with a PowerShell events coming from a single workstation.
Honeypot Results are produced if the number of events
containing matching strings is higher than the
In one of his articles, Sean Metcalf presents an specified threshold. The list of service accounts and
effective method on how to detect Kerberoasting SPNs must be prepared as an input. Listing 5 contains
(Metcalf, 2017). He suggests creating a honeypot - a details of this rule.
fake account, with a fake SPN associated, having
some attributes (e.g. AdminCount) set, making it Listing 5: D05 – Detecting Kerberoasting via PowerShell
attractive for potential attackers. This account has no (snippet).
effective role and privileges in the environment; it is
created merely to attract attackers. Monitoring service source="WinEventLog:Microsoft-Windows-
PowerShell/ Operational" (EventCode=4103 OR
ticket requests for this account gives clear results of EventCode=4104)
malicious activities with a low false positive ratio, |transaction Computer maxpause=15m
since there is no legitimate reason to request tickets maxevents=-1 | eval raw=_raw
|search
for this service. [| inputlookup service_accounts.csv | eval
We named the account Honeypot01 for raw="*" . account . "*"
illustration, but the account should look as legitimate |fields raw]
as possible in reality. Apart from the AdminCount |where eventcount > 2 | ...

Figure 3: Kerberoasting detected in Splunk.

3.3 False Positives and Tuning attacker and nature of the PowerShell logs. The logs
contain blocks of code, which limits parsing and also
The number of false positive detections produced by filtering options, thus the search quality will be
the proposed detection rules depends on several dependent on the quality of the input list of the
factors. Firstly, the usage of obsolete cipher suites in scenario.
the environment. In case these suites are not disabled, Table 2 summarizes the True to False positive
and whitelisting is not entirely implemented, false ratio for the discussed scenarios. Scenario D04
positive detections may appear in the search D01. alerted on no False Positives, and it can be used as a
The second search, D02, contains numeric values reference search. The D02 scenario was tested with
that control thresholds for detection. These need to be three different modifications. Note that filtering on
adjusted, as the number of requests for different both krbtgt and dollar accounts caused two attack
services in a small environment would not be on the attempts to be missed, while producing no false
same level as in large environments. Alternatively, positives. Scenarios D03 and D05 are missing from
the search D02 can be combined with D01 to see the table, since given the fact that we are able to
excessive service ticket requests with suspicious describe our environment so precisely, their False
encryption types only. We tested multiple filtering Positive rate would be always zero.
options to minimize the false positive alerts – filtering Even though there is implementation overhead
out only krbtgt account, adding ticket encryption and changes in the environment are required, we
types and filtering dollar accounts, which increased suggest honeypot and/or PowerShell script
accuracy of the detection scenario significantly. monitoring to be deployed.
Search D03 should not trigger at all unless there
actually is a configuration that allows the use of well-
known ports or external IP addresses. The same 4 CONCLUSIONS
applies to detection using honeypot in D04. There is
no legitimate reason to request a service ticket for the In the paper, we proposed the design of detection
honeypot account. Detected activities are very likely scenarios usable for monitoring the network for a
to be malicious. potential occurrence of a Kerberoasting attack. The
purpose of this attack is to extract service accounts’
Table 2: Summary of detection scenarios efficiency. passwords without the need for any special user
Total True positives Fales positives access rights or privilege escalation.
Scenario Detected
Count % Count %
The main goal was to develop a set of detection
Events
rules, which would be able to detect the
D01 - Possible Kerberoasting attack by using Windows Security
Kerberoasting 13 7 58.85 6 46.15 auditing. We designed, implemented and tested
activity
multiple monitoring scenarios, that can be used as a
D02 - Excessive
service ticket baseline for organizations implementing detection
requests from one 326 7 2.15 319 97.85 mechanisms for their Active Directory environments.
source – filtering
krbtgt account
The detections were presented in Splunk SPL
D02 - Excessive language, however, the detection principles used in
service ticket the searches are not limited to the use of Splunk
requests from one
source – add
10 7 70 3 30 technology.
weak encryption We have shown the detection capabilities of the
types
D02 - Excessive designed rules and found out that the false-positive
service ticket rate of the designed rules may vary. Non-standard
requests from one 5 5 100 0 0 approaches, that use honeypots or PowerShell
source – filter $
accounts monitoring for detection, offer strong detection
D04 - Detecting capabilities with a low false-positive ratio, but carry
Kerberoasting 7 7 100 0 0
with a honeypot on implementation overhead.

If PowerShell is utilized for routine

administration tasks for the specified service ac- ACKNOWLEDGEMENTS
counts, these activities will also be reported by the
search D05. Reliable filtering is quite tricky due to the The authors acknowledge the support of the OP VVV
variety of commands that could be used by a potential
MEYS funded project Metcalf S. (2014). METCALF, Sean. Active Directory
CZ.02.1.01/0.0/0.0/16_019/0000765 “Research Security: MS14-068: Vulnerability in (Active
Center for Informatics”. Directory) Kerberos Could Allow Elevation of
Privilege [online]. © 2011-2017 [visited on 2019-05-
11]. Available from: https://adsecurity.org/?p=525
Metcalf, S. (2017). Active Directory Security: Detecting
REFERENCES Kerberoasting Activity [on- line]. © 2011-2017 [visited
on 2019-05-11]. Available from: https://adsecurity.
Desmond, B; Richards, J; Allen, R; Lowe-Norris, A G. org/?p=3458.
(2013) Active Directory: Designing, Deploying, and Metcalf, S. (2017). Active Directory Security: Detecting
Running Active Directory. In: [on- line]. 5th ed. Kerberoasting Activity Part 2 – Creating a Kerberoast
O’Reilly Media, 2013, chap. 1-2, 9-10 ISBN 978- Service Account Honeypot [online]. © 2011-2017
1449320027. [visited on 2019-05-11]. Available from:
Francis, D. (2017) Mastering Active Directory. In: https://adsecurity.org/?p=3513.
Birmingham: Packt Publishing, 2017, chap. 1-2. ISBN Mitre Corporation. Techniques: Kerberoasting [online].
978-1787289352. 2018 [visited on 2019-05-11]. Available from:
Kotlaba, L. (2019). Detection of Active Directory attacks https://attack.mitre.org/techniques/T1208/
(Bachelor Thesis). FIT CTU in Prague. Schroeder, W. Invoke-Kerberoast.ps1 [software]. GitHub,
Microsoft Corporation. Microsoft Docs: Windows 2016 [visited on 2019-05-11]. Available from:
Authentication [online]. 2016 [visited on 2019-05-11]. https://github.com/EmpireProject/Empire/blob/
Available from: https://docs.microsoft.com/en-us/ master/data/module_source/credentials/Invoke-
windows-server/security/windows- Kerberoast.ps1.
authentication/windows-authentication- overview. Secureauth Corporation. Impacket: GetUserSPNs.py
Microsoft Corporation. [MS-Kile]: Kerberos Protocol [software]. GitHub, 2016 [visited on 2019-05-11].
Extensions [on- line]. 2019 [visited on 2019-05-11]. Available from: https://github.com/SecureAuthCorp/
Available from: https://docs.microsoft.com/ en - us / impacket/blob/master/examples/GetUserSPNs.py.
openspecs / windows _ protocols / ms - kile / 2a32282e Smith, R. F (2006). Security Log Encyclopedia: Windows
- dd48 - 4ad9 - a542 - 609804b02cc9. Security Log Events [online] [visited on 2019-05-11].
Microsoft Corporation (2017). Microsoft Docs: Security Available from: https://www.
auditing: 4769(S, F): A Kerberos service ticket was ultimatewindowssecurity.com/securitylog/encyclopedi
requested. [online]. 2017 [visited on 2019-05-11]. a/default.aspx.
Available from: https://docs.microsoft.com/en- Splunk (2019). Splunk Documentation, available online at
us/windows/security/threat- protection/auditing/event- https://docs.splunk.com/Documentation.
4769.
Microsoft Corporation (2017). Microsoft Docs: Network
security: Configure encryption types allowed for
Kerberos [online]. 2017 [visited on 2019-05-11].
Available from: https://docs.microsoft.com/en-
us/windows / security / threat-protection/security-
policy-settings/network-security-configure-
encryption-types-allowed-for-kerberos.
Microsoft Corporation. Microsoft Docs: Advanced security
audit policy settings [online]. 2017 [visited on 2019-05-
11]. Available from: https://docs. microsoft.com/en-
us/windows/security/threat -
protection/auditing/advanced-security-audit-policy-
settings.
Microsoft Corporation. Microsoft Docs: Security auditing:
Audit Kerberos Service Ticket Operations [online].
2017 [visited on 2019-05-11]. Available from:
https://docs.microsoft.com/en-
us/windows/security/threat-protection/ auditing/audit-
kerberos-service-ticket-operations.
Medin, T, (2014). Attacking Microsoft Kerberos Kicking
the Guard Dog of Hades. In DerbyCon 4.0, Louisville,
USA.
Neuman, C.; Yu, T.; Hartman, S.; Raeburn, K. RFC 4120:
The Kerberos network authentication service (V5)
[online]. 2005 [visited on 2019-05-11]. Available from:
https://tools.ietf.org/html/rfc4120. RFC. MIT.