Skip to content

example-detection-rule.md

Latest commit

 

History

History
483 lines (383 loc) · 18.1 KB

example-detection-rule.md

File metadata and controls

483 lines (383 loc) · 18.1 KB

Sample Output: Generated by the detection-engineer agent. This demonstrates detection rule creation with multi-format output, false positive analysis, and tuning guidance.

Detection Rule: Kerberoasting Activity

Overview

Kerberoasting is an Active Directory attack technique in which an attacker requests Kerberos Ticket Granting Service (TGS) tickets for service accounts that have Service Principal Names (SPNs) registered. The tickets are encrypted with the service account's password hash, which the attacker then takes offline and attempts to crack using tools like hashcat or John the Ripper.

This attack is particularly dangerous because:

  • Any authenticated domain user can request TGS tickets, with no elevated privileges required
  • The cracking occurs offline, generating no additional authentication failures or lockouts
  • Service accounts frequently have weak or long-unchanged passwords
  • Service accounts often have elevated privileges (e.g., membership in Domain Admins, local admin on servers)
  • The attack leaves minimal forensic artifacts if not specifically monitored

MITRE ATT&CK Reference

Field Value
Technique T1558.003: Steal or Forge Kerberos Tickets: Kerberoasting
Tactic Credential Access (TA0006)
Platforms Windows
Permissions Required User (any authenticated domain user)
Data Sources Active Directory: Credential Request (DS0026)

Required Log Sources

Primary: Windows Security Event Log

Event ID Description Log Source Requirements
4769 A Kerberos service ticket was requested Security Audit Kerberos Service Ticket Operations must be enabled (Success + Failure)
4768 A Kerberos authentication ticket (TGT) was requested Security Supplementary context

Audit Policy Configuration

The following audit policy must be enabled via GPO or local policy:

Computer Configuration > Policies > Windows Settings > Security Settings
  > Advanced Audit Policy Configuration > Audit Policies
    > Account Logon > Audit Kerberos Service Ticket Operations: Success, Failure

Verification command:

auditpol /get /subcategory:"Kerberos Service Ticket Operations"
# Expected: Success and Failure

Note: This audit policy must be enabled on all Domain Controllers, as TGS requests are serviced by the DC that holds the account's domain.

Sigma Rule

title: Potential Kerberoasting Activity - Anomalous TGS Request
id: 8f5c2a1d-7e3b-4c9f-a6d8-2e1f5b3c7d9a
status: stable
description: |
  Detects potential Kerberoasting attacks by identifying TGS ticket requests
  using RC4 encryption (0x17) targeting service accounts. Legitimate Kerberos
  traffic typically uses AES256 (0x12) or AES128 (0x11) encryption types.
  RC4 requests for user-based SPNs are a strong indicator of Kerberoasting
  tools such as Rubeus, Invoke-Kerberoast, or Impacket's GetUserSPNs.py.
references:
  - https://attack.mitre.org/techniques/T1558/003/
  - https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/t1208-kerberoasting
  - https://adsecurity.org/?p=2293
  - https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spn-setspn-syntax.aspx
author: Detection Engineering Team
date: 2024/09/15
modified: 2024/09/15
tags:
  - attack.credential_access
  - attack.t1558.003
logsource:
  product: windows
  service: security
detection:
  # Core selection: TGS ticket requests (Event ID 4769)
  selection_event:
    EventID: 4769

  # Focus on RC4 encryption type (0x17 = RC4-HMAC)
  # Kerberoasting tools default to requesting RC4 because it is
  # significantly faster to crack than AES. Legitimate clients
  # should negotiate AES256 (0x12) in modern AD environments.
  selection_encryption:
    TicketEncryptionType: '0x17'

  # Successful ticket issuance only (0x0 = success)
  # Failed requests may indicate a different issue
  selection_success:
    Status: '0x0'

  # Exclude machine accounts (end with $) -- Kerberoasting targets
  # user accounts with SPNs, not computer accounts
  filter_machine_accounts:
    ServiceName|endswith: '$'

  # Exclude krbtgt -- TGT requests, not TGS
  filter_krbtgt:
    ServiceName: 'krbtgt'

  # Exclude common legitimate services that may use RC4
  # for backwards compatibility
  filter_legitimate_services:
    ServiceName:
      - 'kadmin/changepw'
      - 'K/M'

  # Exclude known service accounts used by IT management tools
  # CUSTOMIZE THIS LIST for your environment
  filter_known_requestors:
    TargetUserName:
      - 'svc_sccm$'
      - 'svc_servicenow$'
      - 'svc_monitoring$'

  condition: >
    selection_event and selection_encryption and selection_success
    and not filter_machine_accounts
    and not filter_krbtgt
    and not filter_legitimate_services
    and not filter_known_requestors
falsepositives:
  - IT management tools performing service account enumeration (ServiceNow Discovery, SCCM)
  - Legacy applications that require RC4 encryption
  - Backup solutions querying service account status
  - Security scanning tools performing authorized assessments
level: high

Splunk SPL Translation

`wineventlog_security`
| where EventCode=4769
    AND TicketEncryptionType="0x17"
    AND Status="0x0"

    ```Filter out machine accounts (computer accounts end with $)
    Machine accounts requesting TGS tickets is normal Kerberos behavior```
    AND NOT match(ServiceName, "\$$")

    ```Filter out krbtgt service which is TGT renewal, not TGS```
    AND ServiceName!="krbtgt"

    ```Filter out known legitimate RC4 service requests```
    AND NOT ServiceName IN ("kadmin/changepw", "K/M")

| eval SourceIP=TargetInfo

    ```Calculate request velocity per source to detect bulk Kerberoasting
    Tools like Rubeus request tickets for ALL kerberoastable accounts
    in rapid succession, which is abnormal for legitimate usage```
| bucket _time span=5m
| stats
    count AS tgs_request_count,
    dc(ServiceName) AS unique_spns_requested,
    values(ServiceName) AS targeted_services,
    earliest(_time) AS first_request,
    latest(_time) AS last_request
    BY TargetUserName, SourceIP, _time

    ```Threshold: more than 3 unique SPNs with RC4 in a 5-minute window
    is a strong indicator of automated Kerberoasting. Single SPN
    requests may be legitimate; bulk requests rarely are.```
| where unique_spns_requested > 3

    ```Calculate time spread to further qualify automated behavior```
| eval time_spread_seconds = last_request - first_request
| eval requests_per_second = round(tgs_request_count / max(time_spread_seconds, 1), 2)

    ```Enrich with lookup for known authorized accounts```
| lookup authorized_kerberos_accounts.csv TargetUserName AS TargetUserName OUTPUT is_authorized
| where NOT is_authorized="true"

| table _time, TargetUserName, SourceIP, tgs_request_count, unique_spns_requested,
        targeted_services, requests_per_second
| sort - unique_spns_requested

Required Lookup File: Create authorized_kerberos_accounts.csv with columns TargetUserName,is_authorized for accounts that legitimately perform bulk TGS requests.

Elastic KQL Translation

event.code: "4769"
  AND winlog.event_data.TicketEncryptionType: "0x17"
  AND winlog.event_data.Status: "0x0"
  AND NOT winlog.event_data.ServiceName: *$
  AND NOT winlog.event_data.ServiceName: ("krbtgt" OR "kadmin/changepw" OR "K/M")

Elastic Detection Rule Configuration:

{
  "name": "Potential Kerberoasting Activity",
  "description": "Detects TGS ticket requests using RC4 encryption targeting service accounts, indicative of Kerberoasting.",
  "risk_score": 73,
  "severity": "high",
  "type": "threshold",
  "index": ["winlogbeat-*", "logs-windows.security-*"],
  "query": "event.code:\"4769\" AND winlog.event_data.TicketEncryptionType:\"0x17\" AND winlog.event_data.Status:\"0x0\" AND NOT winlog.event_data.ServiceName:*$ AND NOT winlog.event_data.ServiceName:(\"krbtgt\" OR \"kadmin/changepw\")",
  "threshold": {
    "field": ["winlog.event_data.TargetUserName", "source.ip"],
    "value": 4,
    "cardinality": [
      {
        "field": "winlog.event_data.ServiceName",
        "value": 3
      }
    ]
  },
  "interval": "5m",
  "from": "now-6m",
  "tags": ["Credential Access", "T1558.003", "Kerberoasting"],
  "threat": [
    {
      "framework": "MITRE ATT&CK",
      "tactic": {
        "id": "TA0006",
        "name": "Credential Access",
        "reference": "https://attack.mitre.org/tactics/TA0006/"
      },
      "technique": [
        {
          "id": "T1558",
          "name": "Steal or Forge Kerberos Tickets",
          "reference": "https://attack.mitre.org/techniques/T1558/",
          "subtechnique": [
            {
              "id": "T1558.003",
              "name": "Kerberoasting",
              "reference": "https://attack.mitre.org/techniques/T1558/003/"
            }
          ]
        }
      ]
    }
  ]
}

False Positive Analysis

Known False Positive Scenarios

Source Description Frequency Mitigation
ServiceNow Discovery ServiceNow's Discovery module probes AD service accounts as part of CMDB population. It may request TGS tickets for multiple SPNs during discovery scans. Scheduled (weekly/monthly) Whitelist the ServiceNow MID server IP address and service account
SCCM/MECM System Center Configuration Manager queries service account status during inventory cycles. Scheduled (daily) Whitelist SCCM site server IP and service account (svc_sccm)
Backup Solutions Veeam, Commvault, and similar backup products may enumerate service accounts when discovering SQL Server instances or Exchange databases. Scheduled (nightly) Whitelist backup server IPs
Vulnerability Scanners Nessus, Qualys, and Rapid7 InsightVM may request Kerberos tickets during credentialed scans to validate SPN configurations. Scheduled (weekly) Whitelist scanner IPs during scan windows
Legacy Applications Older applications compiled against pre-AES .NET frameworks or Java versions may legitimately request RC4 TGS tickets. Constant Identify and document these applications; create permanent exceptions
Authorized Penetration Tests Red team or pentest engagements will intentionally trigger this rule. During engagements Coordinate with SOC; suppress alerts from authorized source IPs during engagement windows

Distinguishing True Positives from False Positives

Indicator True Positive (Kerberoasting) False Positive (Legitimate)
Volume 10+ unique SPNs requested in <5 minutes 1-3 SPNs per request cycle
Timing Random, outside maintenance windows Coincides with scheduled scans
Source Workstation or unexpected host Known management server
Account Standard user account Known service/admin account
Pattern Burst of requests, then silence Regular, periodic pattern
Encryption Exclusively RC4 (0x17) Mix of AES and RC4

Tuning Recommendations

Phase 1: Baseline (Week 1-2)

Deploy the rule in alert-only mode (no automated response) to establish a baseline:

```Run this search daily for 2 weeks to identify normal RC4 TGS patterns```
`wineventlog_security` EventCode=4769 TicketEncryptionType="0x17" Status="0x0"
  NOT match(ServiceName, "\$$") NOT ServiceName="krbtgt"
| stats count dc(ServiceName) AS unique_spns values(ServiceName) AS services BY TargetUserName, src_ip
| where unique_spns > 1
| sort - unique_spns

Phase 2: Whitelist Development (Week 2-3)

Based on baseline data, build environment-specific whitelists:

  1. Source IP whitelist: Management servers, scanners, backup servers that legitimately generate RC4 TGS requests
  2. Account whitelist: Service accounts that are expected requestors
  3. SPN whitelist: Specific service names that always use RC4 due to legacy constraints

Phase 3: Threshold Tuning (Week 3-4)

Adjust the threshold based on your environment:

  • High-security environments: Trigger on 2+ unique SPNs with RC4 in 10 minutes
  • Standard environments: Trigger on 4+ unique SPNs with RC4 in 5 minutes (default)
  • Noisy environments: Trigger on 8+ unique SPNs with RC4 in 5 minutes

Phase 4: AES-Only Enforcement (Long-Term)

The most effective tuning is to eliminate RC4 from your environment entirely:

# Set supported encryption types to AES128 + AES256 only via GPO
# Computer Configuration > Policies > Windows Settings > Security Settings
#   > Local Policies > Security Options
#   > "Network security: Configure encryption types allowed for Kerberos"
#   > Enable AES128_HMAC_SHA1 and AES256_HMAC_SHA1 ONLY

# Verify on a per-account basis
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties msDS-SupportedEncryptionTypes |
  Select-Object Name, SamAccountName, @{N='EncTypes';E={$_.'msDS-SupportedEncryptionTypes'}}

Once RC4 is fully deprecated, any RC4 TGS request becomes a high-fidelity alert with near-zero false positives.

Recommended Response Actions

Automated Response (SOAR Playbook)

  1. Immediate (0-5 minutes):

    • Create high-priority incident ticket
    • Enrich alert with user details from AD (group membership, last logon, account creation date)
    • Enrich source IP (hostname, logged-in user, asset criticality)
    • Query SIEM for additional suspicious activity from the same source in the past 24 hours

  2. Triage (5-30 minutes):

    • Determine if the source is a known management server (check whitelist)
    • Determine if there is an active authorized penetration test
    • Check if the requesting account shows other indicators of compromise (impossible travel, new device, password spray source)
    • Query for successful authentication events from the source IP

  3. Containment (if confirmed true positive):

    • Disable the compromised user account
    • Reset passwords for ALL service accounts whose TGS tickets were requested (the attacker already has the encrypted tickets)
    • Isolate the source host from the network
    • Force Kerberos ticket expiration for the compromised account: klist purge on the source host

  4. Investigation (post-containment):

    • Analyze source host for Kerberoasting tools (Rubeus, Invoke-Kerberoast, GetUserSPNs.py)
    • Check for credential dumping artifacts (Mimikatz, lsassy)
    • Review all service accounts targeted. Are any Domain Admins or have elevated privileges?
    • Determine initial access vector (how did the attacker get authenticated domain access?)

Testing and Validation

Method 1: Rubeus (Simulated Kerberoasting)

Run from a domain-joined Windows host with a standard domain user account:

# Request TGS tickets for all kerberoastable accounts
# This WILL trigger the detection rule
.\Rubeus.exe kerberoast /stats
.\Rubeus.exe kerberoast /outfile:hashes.txt

# Request TGS for a specific SPN (targeted -- lower volume)
.\Rubeus.exe kerberoast /spn:MSSQLSvc/db01.corp.acme.local:1433 /outfile:single_hash.txt

Method 2: Invoke-Kerberoast (PowerShell)

# Import the module
Import-Module .\Invoke-Kerberoast.ps1

# Request all kerberoastable tickets
Invoke-Kerberoast -OutputFormat Hashcat | Select-Object -ExpandProperty Hash

Method 3: Impacket (Linux)

# From a Linux attack host with valid domain credentials
GetUserSPNs.py CORP.ACME.LOCAL/testuser:Password1 -dc-ip 10.10.3.10 -request

Validation Checklist

After running any of the above tests, verify:

  • Event ID 4769 with TicketEncryptionType 0x17 appears in the DC Security Event Log
  • The Sigma rule / Splunk search / Elastic rule triggers an alert
  • The alert contains the correct source IP and requesting account
  • The targeted service names are listed in the alert details
  • The threshold logic correctly fires (multiple SPNs, not single requests)
  • Response playbook actions execute as expected (ticket creation, enrichment)
  • Known false positive sources are correctly filtered

Supplementary Detection: Kerberoasting Tool Execution

In addition to detecting the Kerberos protocol-level activity, monitor for the execution of known Kerberoasting tools on endpoints.

Sigma Rule: Kerberoasting Tool Process Creation

title: Kerberoasting Tool Execution Detected
id: 3a7c9e2d-5f1b-48d6-b3a7-c8e2f1d5a9b6
status: stable
description: |
  Detects the execution of known Kerberoasting tools based on process name,
  command-line arguments, and file hashes.
references:
  - https://attack.mitre.org/techniques/T1558/003/
author: Detection Engineering Team
date: 2024/09/15
tags:
  - attack.credential_access
  - attack.t1558.003
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  # Detect Rubeus kerberoast subcommand
  selection_rubeus:
    CommandLine|contains|all:
      - 'Rubeus'
      - 'kerberoast'

  # Detect Invoke-Kerberoast PowerShell usage
  selection_invoke_kerberoast:
    CommandLine|contains: 'Invoke-Kerberoast'

  # Detect Impacket's GetUserSPNs (via Python or compiled)
  selection_getuserspns:
    CommandLine|contains: 'GetUserSPNs'

  # Detect known tool binary names
  selection_binary_names:
    Image|endswith:
      - '\Rubeus.exe'
      - '\kerberoast.exe'
      - '\GetUserSPNs.exe'

  # Detect hashcat with Kerberos mode (13100 = Kerberoast)
  selection_hashcat_kerberos:
    CommandLine|contains|all:
      - 'hashcat'
      - '13100'

  condition: 1 of selection_*
falsepositives:
  - Authorized penetration testing
  - Security tool evaluation
level: critical

Splunk SPL: Tool Execution Detection

`sysmon` EventCode=1
| where match(CommandLine, "(?i)(rubeus.*kerberoast|invoke-kerberoast|getuserspns)")
    OR match(Image, "(?i)(rubeus\.exe|kerberoast\.exe|getuserspns\.exe)$")
    OR match(CommandLine, "(?i)hashcat.*13100")
| table _time, ComputerName, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort _time

Detection rule designed for environments running Windows Server 2016+ with Advanced Audit Policy configured. Test in a lab environment before production deployment. Adjust thresholds and whitelists based on 2-week baseline observation period.