« Potential Kerberos SPN Spoofing via Suspicious DNS Query Access to a Sensitive LDAP Attribute »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.23

Kirbi File Creation

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Kirbi File Creation

edit

Identifies the creation of .kirbi files, a suspicious Kerberos ticket artifact often produced by ticket export or dumping tools such as Rubeus or Mimikatz. This can indicate preparation for Kerberos ticket theft or later abuse, including Pass-The-Ticket (PTT), and should be validated with writer process and follow-on activity.

Rule type: eql

Rule indices:

  • logs-endpoint.events.file-*
  • logs-windows.sysmon_operational-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-m365_defender.event-*
  • winlogbeat-*
  • endgame-*
  • logs-crowdstrike.fdr*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: SentinelOne
  • Data Source: Microsoft Defender XDR
  • Data Source: Elastic Endgame
  • Data Source: Crowdstrike
  • Resources: Investigation Guide

Version: 316

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Kirbi File Creation

Possible investigation steps

  • What does the alert-local ticket artifact show?
  • Focus: file.path, file.name, file.extension, file.size, and @timestamp, plus host.id and user.id for scope.
  • Implication: escalate when a ".kirbi" file lands in temp, public, user-profile, archive, or tool-staging paths, when file.name encodes a user, service, or realm, or when size and naming fit ticket export; lower suspicion only when the artifact path, name, host, and user match one known evidence-collection pattern before any workflow corroboration.
  • Which process wrote the ticket file?
  • Focus: writer identity and launch context: process.executable, process.pe.original_file_name, process.code_signature.subject_name, and process.parent.executable; use process.entity_id only to scope this process instance.
  • Hint: if only process.pid is present, recover the writer with host.id, process.pid, and a tight window around @timestamp.
  • Implication: escalate when unsigned, renamed, script- or shell-launched, or user-writable tooling writes the file; lower suspicion only when identity, signer, parent, and path match a recognized testing or IR workflow. Trusted identity alone does not clear ticket export.
  • Does the command line or lineage show ticket export or ticket-use intent?
  • Focus: process.command_line, process.parent.command_line, and surrounding process events for the same host.id and process.entity_id, or process.pid when entity IDs are absent. !{investigate{"description":"","label":"Process events for the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when arguments or lineage show dump, export, outfile, archive staging, Mimikatz/Rubeus-style verbs, "ptt", "kerberos::ptt", scripting, or remote-admin chains; lower suspicion only when command line and lineage fit the same confirmed test or troubleshooting workflow.
  • Did the same writer stage more tickets or hide them?
  • Focus: file events for host.id and process.entity_id: file.path and file.name for additional ".kirbi" writes, renames, archives, or extension changes. !{investigate{"description":"","label":"File events for the same process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"file","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Implication: escalate when the writer creates several ticket files, renames them into archives, removes the extension, or stores them beside collection tools; one unchanged ticket in a controlled evidence directory lowers scope but does not close by itself.
  • How sensitive is the user and host context?
  • Focus: host.name, user.id, user.name, and user.domain.
  • Implication: escalate faster when a domain, service, or privileged identity writes the ticket, or when the same host/user also shows staging or follow-on use; lower severity only when a constrained lab identity and lab host match the telemetry and corroborating case evidence.
  • Is there follow-on ticket import, remote access, or lateral movement after export?
  • Why: ".kirbi" creation proves ticket material was written; risk increases sharply if the same host or user tries to use it.
  • Focus: start with direct child process events from the writer process using host.id with process.parent.entity_id, or process.parent.pid when entity IDs are absent. !{investigate{"description":"","label":"Child process events from the writer process","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.parent.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}} Expand manually to broader later process activity for the same host.id or user.id when needed, especially process.command_line.
  • Implication: escalate when later commands show "ptt", "kerberos::ptt", "klist", remote execution, archive movement, or access to new systems after export; matching authentication or connection telemetry can corroborate impact, but missing telemetry is unresolved, not benign.
  • If local evidence stays suspicious or unresolved, do related alerts broaden the case?
  • Focus: related credential-access, lateral-movement, archive, and suspicious-authentication alerts for user.id in the last 48 hours. !{investigate{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Hint: use the same alert families for host.id when host scope, not user scope, decides containment. !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • Implication: broaden containment when related alerts align with ticket export, dumping, archive staging, remote access, or privilege escalation; keep response local when related alerts are absent or unrelated, but do not use absence alone to close the ".kirbi" alert.
  • Based on the evidence gathered, what disposition is supported?
  • Focus: artifact path and naming, writer identity and lineage, command intent, staging, user/host sensitivity, and follow-on activity.
  • Implication: escalate when artifact, writer, command, staging, sensitive-context, or follow-on evidence points to unauthorized ticket export or use; close only when the same evidence categories tightly bind one recognized red-team, IR, or Kerberos-troubleshooting workflow and no contradictory evidence remains; preserve and escalate when evidence is mixed or incomplete.

False positive analysis

  • Red-team, purple-team, IR, and Kerberos troubleshooting workflows can legitimately export tickets, but close only after telemetry binds the exact workflow. Confirm that writer identity, parent context, command line, user.id, host.id, and output file.path all align, and that no ticket-import or remote-access follow-on appears; use case, exercise, or troubleshooting records only as corroboration. Use prior alerts only to validate exception stability after the current evidence aligns; do not close the current alert on recurrence alone. Treat production-domain-controller, admin-workstation, or service-account activity as suspicious unless it is explicitly in scope for the same case or exercise.
  • Build exceptions from the minimum confirmed workflow pattern: process.executable, process.pe.original_file_name, process.code_signature.subject_name, process.parent.executable, process.command_line, user.id, host.id, and output path pattern. Avoid exceptions on ".kirbi" extension, host, or user alone.

Response and remediation

  • If confirmed benign, reverse temporary containment and document the writer identity, parent context, command line, user, host, and output path that proved the recognized workflow. Create an exception only after the same pattern recurs across prior alerts.
  • If suspicious but unconfirmed, preserve the ".kirbi" file path, any archive path, the writing process.entity_id, command line, parent chain, user/host context, same-process file events, and follow-on process or authentication evidence before containment. Apply reversible containment first, such as suspending the exporting process or temporarily restricting administrative egress if the host role can tolerate it. Escalate to host isolation or account containment only when follow-on ticket use, privileged-host involvement, or repeated exports show progression.
  • If confirmed malicious, preserve the process, file, parent-chain, identity, staging, and follow-on evidence set before containment or cleanup. Then isolate or otherwise contain the affected host when artifact, writer, command, staging, or follow-on evidence establishes unauthorized ticket export or use, weighing critical host role before isolation. Contain impacted accounts or service principals when the user context or follow-on activity shows their tickets may be usable. If direct endpoint response is unavailable, hand off the preserved evidence to the team that can act.
  • Record process and file identifiers before deleting ticket files, terminating tools, or removing scripts. Revoke or expire exposed Kerberos sessions for affected identities and force reauthentication where appropriate. If evidence shows privileged-ticket theft or Pass-the-Ticket from administrative systems, reset or rotate affected credentials by privilege tier; reserve KRBTGT rotation for confirmed broader Kerberos compromise under the organization’s runbook.
  • Eradicate only the dumping tools, scripts, staged ".kirbi" files, archives, and persistence mechanisms found during the investigation, then remediate the initial access or privilege path that allowed ticket export.
  • After containment, hunt for the same output paths, writer lineage, ticket-import commands, and staged archives across other systems.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"

Framework: MITRE ATT&CKTM

« Potential Kerberos SPN Spoofing via Suspicious DNS Query Access to a Sensitive LDAP Attribute »