Detection Indicators

Login-Based Indicators:

• Unusual login frequency: Higher than usual login attempts, especially for sensitive accounts like password managers, may indicate a brute-force attack.

• Unexpected account lockouts: A sudden lockout can happen if an attacker changes the password.

• Honeywords triggered: If decoy passwords (honeywords) are used in login attempts, it suggests an attacker got the website's password database.

• Suspicious password reset requests: A sudden spike, especially from unusual sources, warrants investigation.

Email-based Indicators:

• Email Templates: Phishing kits frequently use pre-designed email templates for reporting stolen credentials. These templates often mimic legitimate emails from banks, social media platforms, or other services. Analyzing email templates and flagging suspicious emails can help identify phishing attacks.

• Spoofed Emails: These emails are meticulously crafted to impersonate trusted entities like banks, credit card companies, or popular websites. Phishers may use logos, official-looking layouts, and even forge sender addresses to appear legitimate.

• Suspicious Links: Phishing emails often contain links that, when clicked, lead the victim to fake websites (cloned sites) designed to look like the real thing. These cloned sites trick users into entering their login credentials or other sensitive information.

• Suspicious emails sent from compromised accounts: Monitor for emails originating from accounts that you know have been compromised. These emails might contain requests for password resets, urgent requests for money, or requests for sensitive data.

• Unusual email activity: A sudden increase in spam or other malicious emails sent from a user's account is a major red flag. This suggests that the account has been compromised and is being used for unauthorized purposes.

• Suspicious login alerts: Many email providers offer alerts for suspicious login attempts, such as logins from unusual locations or devices. These alerts can be a valuable early warning sign of a potential phishing attack.

Kerberoasting Attack Indicators:

• High volume of diverse service requests: A large number of different service requests within a short time frame from a single source could be a sign of an attacker trying to gain access to multiple services. Establishing a baseline and detecting deviations can be valuable.

• Requests for service tickets using weak encryption types: Kerberoasting often relies on weaker encryption that can be more easily cracked offline. Be vigilant for legacy protocols like RC4.

• Suspicious external service ticket requests: Requests coming from external sources or unusual IP addresses might be an attempt to exploit the Kerberos protocol from outside the network.

• Service ticket requests for accounts with servicePrincipalName (SPN): Attackers target these specific accounts, so unusual or excessive requests for them should raise concerns.

• PowerShell logs containing service account names or SPNs: Tools like Rubeus and Mimikatz, commonly used in Kerberoasting, may leave traces in PowerShell logs.

Windows Event Logs:

• Analyze specific fields in Windows Event ID 4769 (A Kerberos service ticket was requested):

  • Service name is not equal to 'krbtgt'

  • Failure code is '0x0'

  • Ticket encryption type is '0x17'

Account Configuration

• UserAccountControl Settings:

  • "Don't require Kerberos pre-authentication" setting enabled: This could make the system vulnerable to a targeted Kerberoasting attack.

• SPN Value Changes:

  • Any modifications to the service principal name (SPN) value of a user account could be a sign of an attack.

Golden Ticket attacks

• Usernames that do not exist in the domain: This is a clear sign that something is wrong. A legitimate Kerberos ticket should be associated with a valid user in the domain.

• Modified group memberships (added or removed): Golden Tickets can be forged to grant a user unauthorized access by adding them to privileged groups. Conversely, attackers might remove a user from groups they legitimately belong to in order to restrict their access.

• Mismatches between usernames and relative identifiers (RIDs): Each user account in Active Directory has a unique RID. A mismatch between the username and its corresponding RID in a Kerberos ticket is a strong indicator of tampering.

• Weaker encryption types (e.g., RC4 instead of AES-256): While older weaker encryption types might still be supported for compatibility reasons, their use in newly generated Kerberos tickets is uncommon and could indicate a forged ticket.

• Unusual Ticket Lifetimes: Golden Tickets are often created with very long lifetimes, sometimes years or even indefinite. Monitoring for Kerberos tickets with excessively long lifetimes can be an indicator of a potential attack.

• Compromised KRBTGT Account Activity: Golden Tickets are typically issued by a compromised KRBTGT account, which is responsible for Kerberos ticket-granting ticket (TGT) encryption. Monitoring for unusual activity related to the KRBTGT account, such as password changes or failed login attempts from unexpected locations, can be a sign of a potential attack.

• Golden Ticket Tool Usage: Tools like Mimikatz can be used to create Golden Tickets. Detecting the use of these tools on systems or in network traffic can be a strong indicator of Golden Ticket activity.

• High-Privileged Actions from Unusual Accounts: If an account with low privileges suddenly performs high-privileged actions, it could be a sign of a Golden Ticket attack. Monitoring for unusual activity from accounts, especially those not typically associated with administrative tasks, can help detect such attacks.

Silver Ticket attacks

• Tickets with specific service names: Silver Tickets are typically created for specific services that may not be commonly used on a system. For example, a Silver Ticket targeting the CIFS service (used for file sharing) on a workstation would be suspicious. Monitor Kerberos tickets for service names that don't correspond to legitimate services running on a system.

• Tickets with unusual encryption types: Legitimate Kerberos tickets use specific encryption types. Tickets with unexpected encryption types or other structural irregularities could be signs of Silver Tickets.

• Use of Silver Ticket tools: Tools like Mimikatz are known to be used for creating Silver Tickets. Detecting the use of these tools on systems or in network traffic can be a strong indicator of malicious activity.

• Unusual service behavior: A service that starts behaving abnormally, such as accessing unauthorized resources or performing actions outside its typical functions, could be compromised using a Silver Ticket. Monitor for unusual service behavior to identify potential attacks.

• Silver Ticket Forgery: Forged Kerberos tickets can grant attackers persistent access to systems. Look for anomalies in Kerberos ticket events, such as blank or incorrect account domain fields, or the presence of unusual strings in event logs, which may be indicators of tampering.

Pass-the-Hash (PtH):

PtH attacks exploit the inherent weaknesses of storing hashed credentials for authentication. Attackers can steal these hashes and use them to authenticate to other systems on the network, enabling them to move laterally and gain access to more sensitive resources.

• Lateral movement with reused credentials: Monitor for logins from multiple systems using the same credentials, especially within a short timeframe. This is a strong indicator of PtH activity, as legitimate users are unlikely to access multiple systems in a short period using the same credentials.

• Authentication from unusual locations: Look for logins from unexpected geographic locations or unusual systems. Users typically access systems from consistent locations and devices. Deviations from this pattern can indicate unauthorized access attempts.

• Use of PtH tools (e.g., Mimikatz): Detecting the use of such tools on systems or in network traffic is a strong indicator of PtH activity. Security solutions can monitor for known PtH tools and raise alerts when they are detected.

• Successful logon events followed by failed network logon attempts: This can occur when an attacker attempts to use the stolen hash for network authentication, which might fail due to network restrictions or security measures in place. For example, multi-factor authentication (MFA) can thwart PtH attacks by requiring an additional factor beyond the stolen hash for successful authentication.

Event Log Analysis:

• Event ID 4768, 4769 (Domain Controller Logs): These events indicate Kerberos ticket requests (4768) and grants (4769). Monitoring these events for anomalies, such as requests from unusual sources or at unexpected times, can help detect OPtH activity. Pay close attention to the "Client Address" and "Account Name" fields to identify suspicious patterns.

• Security Event Logs (Event ID 4624): These events record successful logon attempts. Look for successful logons with a logon type of "NetworkCleartext" or "9," which could indicate the use of clear-text credentials in an OPtH attack.

Endpoint Analysis:

• Examine endpoints for signs of hash theft, such as the presence of suspicious tools like Mimikatz or Rubeus, or unusual processes accessing credential stores (e.g., LSASS).

• Look for evidence of lateral movement or privilege escalation, which may be indicative of a successful OPtH attack.

Network Traffic Analysis:

• Monitor network traffic for Kerberos authentication requests, particularly for TGT requests and TGS responses. Look for unusual patterns or requests originating from compromised systems.

• Consider implementing a Network Detection and Response (NDR) solution to analyze network traffic in real-time and identify suspicious Kerberos activity.

Pass-the-Ticket (PtT) Attack

PtT involves stealing a valid Kerberos ticket and using it to impersonate a user or service to gain unauthorized access to resources. Attackers can steal tickets through various methods, including phishing attacks, malware infections, or exploiting vulnerabilities in Kerberos implementations.

Domain Controller (DC) Logs:

Event ID 4769 (Kerberos service ticket request):

• Look for TGS requests or TGT renewals without a corresponding TGT request from the same client within the previous 10 hours. This could indicate that an attacker stole a TGT and is using it to request additional service tickets.

• Look for TGTs with lifetimes different from the domain policy's MaxTicketAge (default is 10 hours). A significantly longer lifetime could be a sign of a forged ticket.

• Look for event ID 4769 where the Account Information and Service Information sections reference the same account. This is suspicious because a service ticket should typically be used to access a different service than the one that issued the TGT.

• Look for event ID 4769 where the "Services in Transit" attribute in the Additional Information is not empty. This attribute is typically empty and can indicate suspicious activity.

Unrestricted Delegation Attack:

Suspicious Service Account Activity: Monitor the activity of service accounts, especially those with Unconstrained Delegation enabled. Any unexpected behavior, such as accessing unusual resources or generating excessive traffic, could be a sign of an attack. This might include attempts to access highly sensitive data, connect to unusual systems, or perform actions outside the typical functionality of the service account.

Event ID 4624: Successful logon events with a Logon Type of "NetworkCleartext" or "9" might indicate the use of clear-text credentials in an Unrestricted Delegation attack. This can occur because Unconstrained Delegation bypasses the usual Kerberos authentication process, potentially revealing user credentials in plain text during the attack.

Kerberos Ticket Anomalies: Look for unusual Kerberos ticket requests, such as requests from unexpected sources or for services that the compromised service doesn't typically access. For example, if a web server account requests a ticket for a database server it doesn't normally interact with, this could be a sign of an attacker impersonating a user to access the database.

Location and Time Anomalies

• Logins from unfamiliar or unexpected locations, especially compared to a user's established baseline of typical login behavior. User baseline data can be established by analyzing past login activity and identifying patterns such as usual login locations, times, and devices. Significant deviations from these patterns could warrant further investigation.

• Inconsistent geolocation transitions between logins. This can occur when attackers attempt to mask their location by using proxy servers or VPNs. By monitoring for sudden shifts in geolocation data, security systems can identify potentially suspicious activity.

• Traffic to or from the Key Distribution Center (KDC) from unusual locations. The KDC is a critical component responsible for issuing and managing encryption keys. A surge in traffic, particularly directed towards unfamiliar locations, could indicate a credential stuffing attack or other malicious activity targeting authentication systems.

• Logins at odd hours, outside of normal business hours. Login attempts outside of a user's established timeframes can be a sign of unauthorized access. For example, a login attempt at 3 am from a location where the user typically works during business hours might be suspicious.

• Spikes in network traffic during odd hours. Similar to unusual login times, unexpected surges in network traffic outside of standard working hours could indicate malicious activity, especially if the traffic originates from or is directed towards unfamiliar locations.

File-Based Indicators:

• Unexpected DLLs: DLL files known to be associated with vulnerabilities or malicious activity. These DLLs may be used for privilege escalation, process injection, or other techniques to compromise a system.

• Unexpected File Hash Changes: Use file-integrity tools to track changes in the hashes of critical files (e.g., OpenSSL library, SAM database, LSA secrets). Unexpected changes in the hash of a critical file could indicate that the file has been tampered with by an attacker.

• Unauthorized Downloads: Downloads of unauthorized tools (especially related to authentication) or files from unusual sources. Attackers may download malicious tools or scripts to compromise a system. Be alert to downloads from unofficial sources or downloads of files associated with known vulnerabilities.

• Backup and Snapshot Activities: Unauthorized access to backup files or snapshot creation, especially on domain controllers. Attackers may attempt to steal credentials or other sensitive information from backups or snapshots.

Processes and Command Indicators

• Unusual commands executed remotely, especially those related to credential management or system information gathering. These can include commands to dump password hashes, list domain users, or access system secrets.

• Processes with names designed to mimic legitimate system tools (e.g., "scvhost.exe" instead of "svchost.exe"). This technique, known as process name spoofing, attempts to evade detection by appearing like a legitimate system process.

• Processes started by unusual parent processes (e.g., cmd.exe started by a web browser). Legitimate child processes are typically spawned by their expected parent processes. Unexpected parent-child relationships can indicate malicious injection or exploitation.

• Processes with hidden windows or processes resisting termination. Attackers may attempt to hide malicious processes to avoid detection and prevent them from being shut down.

• Processes requesting SeDebugPrivilege. This privilege is often abused by credential dumping tools to access the memory of the LSASS process, where credentials may be stored. Monitoring for processes attempting to enable or use this privilege can be a red flag for potential credential theft.

• Excessive reads from LSASS memory within a short time frame. This rapid access could signal a credential dumping tool attempting to extract a large volume of data in one go.

• Processes injecting code into LSASS. Legitimate applications typically wouldn't require injecting code into LSASS, so this behavior is a red flag.

• Attempts to rename, hide, or obfuscate processes accessing LSASS. Attackers might try to mask their activity by manipulating process names or using obfuscation techniques. This should trigger further investigation.

• Processes consuming a disproportionate amount of CPU or RAM compared to their usual resource utilization. A sudden spike in resource usage can indicate a process working overtime, potentially due to malicious activity like credential dumping.

Suspicious Activity on Domain Controllers:

• Creation of unexpected volume shadow copies. Volume shadow copies create backups of data, and while they have legitimate uses, attackers might leverage them to capture snapshots of memory containing credentials.

• Tools like secretsdump.py executed on domain controllers. Secretsdump.py is a well-known tool used for extracting credentials from Active Directory. Its presence on a domain controller is a high-alert indicator.

Credential Exposure Indicators

• Presence in Known Data Breaches: This is the single most critical indicator. If a username and password pair shows up in a known data breach dataset, it's highly likely to be used in a credential stuffing attack. Criminals can purchase these breach datasets on the dark web and use automated tools to attempt logins across multiple platforms with the stolen credentials.

• Dark Web/Darknet Activity: Monitoring activity on dark web forums and marketplaces can reveal plans for upcoming attacks, lists of targeted accounts or credentials, or discussions about successful compromises using stolen credentials.

• Publicly Shared Credentials: Occasionally, users may carelessly expose their credentials on public sites or forums. While this doesn't necessarily mean the credentials were obtained through a data breach, it indicates that the credentials are not being securely stored and could be vulnerable to attack.

User and Account Behavior Changes

• Sudden Changes in User Patterns: Abrupt shifts in online behavior or activity can be a sign of compromised credentials. This could include logging in from unusual locations or devices, accessing atypical files or resources, or making unexpected changes to account settings.

• Changes in System Configuration: Unexpected modifications to browser user agents or system information can indicate that malware or an attacker is manipulating the system to appear legitimate. This could involve changes to the operating system settings, browser extensions, or other system configurations.

• Slow or Unusual Computer Behavior: Performance issues, such as slowness, crashes, or freezes, can be caused by credential-stealing malware running in the background. These programs may consume system resources or tamper with critical processes to steal login credentials or other sensitive information.

Credential Theft

Keyloggers are malicious programs that can steal keystrokes, clipboard data, and other user input. They can be installed on a device through various methods, such as phishing emails, malicious downloads, or physical access. To detect keyloggers, organizations can implement a combination of security measures. This includes deploying anti-malware software that can scan for and remove known keyloggers. Additionally, application whitelisting can be used to restrict the execution of unauthorized programs that could potentially be keyloggers.

Group Policy Preferences (GPP) is a feature in Active Directory that allows administrators to configure various settings on user and computer accounts. These settings can include passwords, which are stored in SYSVOL, a shared file system used by domain controllers. If an attacker gains access to SYSVOL, they can potentially extract the stored GPP passwords and use them to compromise user accounts. To mitigate this risk, it's crucial to secure GPP credentials properly. This involves using strong passwords and restricting access to SYSVOL only to authorized personnel.

Brute-force attacks involve systematically trying a large number of possible usernames and passwords to gain unauthorized access to a system. Monitor for an unusually high number of login attempts from a single IP address within a short period. This could be a sign that an attacker is using a bot or automated script to try different login combinations. Correlate lockouts with failed login attempts. If a surge in login attempts coincides with a spike in account lockouts, it's more likely to be a brute-force attack rather than legitimate users forgetting their passwords.