KiRBi ticket for mimikatz

Hunt Hypothesis

This detection identifies adversaries leveraging Mimikatz to extract and replay Kerberos tickets, a technique often used to establish persistence or move laterally within an Active Directory environment without triggering standard authentication alerts. Proactively hunting for these specific KiRBi ticket patterns in Azure Sentinel is critical because low-severity signals can mask sophisticated credential theft campaigns that rely on legitimate-looking ticket reuse rather than brute-force attacks.

YARA Rule

rule mimikatz_kirbi_ticket
{
	meta:
		description		= "KiRBi ticket for mimikatz"
		author			= "Benjamin DELPY (gentilkiwi); Didier Stevens"

	strings:
		$asn1			= { 76 82 ?? ?? 30 82 ?? ?? a0 03 02 01 05 a1 03 02 01 16 }
		$asn1_84		= { 76 84 ?? ?? ?? ?? 30 84 ?? ?? ?? ?? a0 84 00 00 00 03 02 01 05 a1 84 00 00 00 03 02 01 16 }

	condition:
		$asn1 at 0 or $asn1_84 at 0
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 2 string patterns in its detection logic.

• Source Rule

False Positive Guidance

Here are 5 specific false positive scenarios for the KiRBi ticket for mimikatz detection rule, including suggested filters or exclusions:

• Scheduled Security Audits using Microsoft Sysinternals Suite

  • Scenario: A weekly automated security audit job runs on domain controllers to collect memory dumps and credential snapshots. The script explicitly launches mimikatz.exe with the sekurlsa::logonpasswords module to verify password hash integrity across the environment.
  • Filter/Exclusion: Create an exclusion for the specific process path (e.g., C:\Program Files\SecurityAudit\Scripts\mimikatz.exe) and restrict the alert to only trigger when the parent process is the scheduled task executable (svchost.exe or a dedicated runner like TaskScheduler) rather than interactive user sessions.

• Identity Management Tool Deployment (e.g., BeyondTrust or CyberArk)

  • Scenario: The enterprise Identity and Access Management (IAM) solution utilizes Mimikatz as an internal engine to perform just-in-time credential rotation for service accounts. This occurs during the daily maintenance window where the IAM agent spawns mimikatz.exe to extract and rotate secrets from the Local Security Authority Subsystem Service (LSASS).
  • Filter/Exclusion: Whitelist the specific user account used by the IAM service (e.g., svc-identity-agent) and exclude events originating from known application installation directories associated with the vendor (e.g., paths containing \BeyondTrust\ or \CyberArk\).

• IT Helpdesk Remote Support Sessions

  • Scenario: Tier 2 support engineers utilize a remote desktop tool (such as Ivanti Endpoint Manager or TeamViewer) that bundles Mimikatz to diagnose authentication issues on user workstations. When an engineer connects to troubleshoot a “cannot log in” ticket, the tool