Kirbi File Creation

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2023/08/23"
  3integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender", "crowdstrike"]
  4maturity = "production"
  5updated_date = "2026/04/24"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the creation of .kirbi files, a suspicious Kerberos ticket artifact often produced by ticket export or
 11dumping tools such as Rubeus or Mimikatz. This can indicate preparation for Kerberos ticket theft or later abuse,
 12including Pass-The-Ticket (PTT), and should be validated with writer process and follow-on activity.
 13"""
 14from = "now-9m"
 15index = [
 16    "logs-endpoint.events.file-*",
 17    "logs-windows.sysmon_operational-*",
 18    "logs-sentinel_one_cloud_funnel.*",
 19    "logs-m365_defender.event-*",
 20    "winlogbeat-*",
 21    "endgame-*",
 22    "logs-crowdstrike.fdr*",
 23]
 24language = "eql"
 25license = "Elastic License v2"
 26name = "Kirbi File Creation"
 27references = [
 28    "https://attack.mitre.org/techniques/T1558/",
 29]
 30risk_score = 73
 31rule_id = "b8f8da2d-a9dc-48c0-90e4-955c0aa1259a"
 32severity = "high"
 33tags = [
 34    "Domain: Endpoint",
 35    "OS: Windows",
 36    "Use Case: Threat Detection",
 37    "Tactic: Credential Access",
 38    "Data Source: Elastic Defend",
 39    "Data Source: Sysmon",
 40    "Data Source: SentinelOne",
 41    "Data Source: Microsoft Defender XDR",
 42    "Data Source: Elastic Endgame",
 43    "Data Source: Crowdstrike",
 44    "Resources: Investigation Guide",
 45]
 46timestamp_override = "event.ingested"
 47type = "eql"
 48
 49query = '''
 50file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi"
 51'''
 52
 53note = """## Triage and analysis
 54
 55### Investigating Kirbi File Creation
 56#### Possible investigation steps
 57
 58- What does the alert-local ticket artifact show?
 59  - Focus: `file.path`, `file.name`, `file.extension`, `file.size`, and `@timestamp`, plus `host.id` and `user.id` for scope.
 60  - 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.
 61
 62- Which process wrote the ticket file?
 63  - 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.
 64  - Hint: if only `process.pid` is present, recover the writer with `host.id`, `process.pid`, and a tight window around `@timestamp`.
 65  - 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.
 66
 67- Does the command line or lineage show ticket export or ticket-use intent?
 68  - 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_3
 69  - 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.
 70
 71- Did the same writer stage more tickets or hide them?
 72  - 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_0
 73  - 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.
 74
 75- How sensitive is the user and host context?
 76  - Focus: `host.name`, `user.id`, `user.name`, and `user.domain`.
 77  - 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.
 78
 79- Is there follow-on ticket import, remote access, or lateral movement after export?
 80  - Why: ".kirbi" creation proves ticket material was written; risk increases sharply if the same host or user tries to use it.
 81  - 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_4 Expand manually to broader later process activity for the same `host.id` or `user.id` when needed, especially `process.command_line`.
 82  - 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.
 83
 84- If local evidence stays suspicious or unresolved, do related alerts broaden the case?
 85  - Focus: related credential-access, lateral-movement, archive, and suspicious-authentication alerts for `user.id` in the last 48 hours. $investigate_1
 86  - Hint: use the same alert families for `host.id` when host scope, not user scope, decides containment. $investigate_2
 87  - 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.
 88
 89- Based on the evidence gathered, what disposition is supported?
 90  - Focus: artifact path and naming, writer identity and lineage, command intent, staging, user/host sensitivity, and follow-on activity.
 91  - 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.
 92
 93### False positive analysis
 94
 95- 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.
 96- 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.
 97
 98### Response and remediation
 99
100- 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.
101- 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.
102- 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.
103- 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.
104- 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.
105- After containment, hunt for the same output paths, writer lineage, ticket-import commands, and staged archives across other systems.
106"""
107
108setup = """## Setup
109
110This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
111
112Setup instructions: https://ela.st/install-elastic-defend
113
114### Additional data sources
115
116This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
117
118- [CrowdStrike](https://ela.st/crowdstrike-integration)
119- [Microsoft Defender XDR](https://ela.st/m365-defender)
120- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
121- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
122"""
123
124[rule.investigation_fields]
125field_names = [
126    "@timestamp",
127    "host.id",
128    "user.id",
129    "process.entity_id",
130    "process.pid",
131    "process.executable",
132    "process.command_line",
133    "process.pe.original_file_name",
134    "process.parent.executable",
135    "process.parent.command_line",
136    "process.code_signature.subject_name",
137    "process.code_signature.trusted",
138    "file.path",
139    "file.name",
140    "file.size",
141]
142
143[[transform.investigate]]
144label = "File events for the same process"
145description = ""
146providers = [
147  [
148    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
149    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
150    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
151  ]
152]
153relativeFrom = "now-1h"
154relativeTo = "now"
155
156[[transform.investigate]]
157label = "Alerts associated with the user"
158description = ""
159providers = [
160  [
161    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
162    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
163  ]
164]
165relativeFrom = "now-48h/h"
166relativeTo = "now"
167
168[[transform.investigate]]
169label = "Alerts associated with the host"
170description = ""
171providers = [
172  [
173    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
174    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
175  ]
176]
177relativeFrom = "now-48h/h"
178relativeTo = "now"
179
180[[transform.investigate]]
181label = "Process events for the writer process"
182description = ""
183providers = [
184  [
185    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
186    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
187    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
188  ],
189  [
190    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
191    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
192    { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
193  ]
194]
195relativeFrom = "now-1h"
196relativeTo = "now"
197
198[[transform.investigate]]
199label = "Child process events from the writer process"
200description = ""
201providers = [
202  [
203    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
204    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
205    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
206  ],
207  [
208    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
209    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
210    { excluded = false, field = "process.parent.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
211  ]
212]
213relativeFrom = "now-1h"
214relativeTo = "now"
215
216[[rule.threat]]
217framework = "MITRE ATT&CK"
218[[rule.threat.technique]]
219id = "T1003"
220name = "OS Credential Dumping"
221reference = "https://attack.mitre.org/techniques/T1003/"
222
223[[rule.threat.technique]]
224id = "T1558"
225name = "Steal or Forge Kerberos Tickets"
226reference = "https://attack.mitre.org/techniques/T1558/"
227
228[rule.threat.tactic]
229id = "TA0006"
230name = "Credential Access"
231reference = "https://attack.mitre.org/tactics/TA0006/"

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_3
    • 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_0
    • 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_4 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_1
    • Hint: use the same alert families for host.id when host scope, not user scope, decides containment. $investigate_2
    • 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.

References

Related rules

to-top