SSSD Kerberos secrets database opened on Linux

Siemphony@siemphonylowT1558unverified

AN1444 is the only leg of DET0522 whose observable survives as a single event: a process touching the SSSD secrets store, `/var/lib/sss/secrets/secrets.ldb` and its master key `.secrets.mkey`, which on a domain-joined Linux host holds the cached Kerberos key material an adversary needs before any ticket can be reused or forged. The match is on the auditd PATH record's own `name` field, and it is split into an absolute-path selection and a filename selection because auditd records `name=` exactly as it was handed to the syscall, so a copy run from inside the directory logs a bare `secrets.ldb`. Two limits are structural rather than chosen. auditd emits PATH and SYSCALL as separate records for one event, so the reading process's `exe`, `uid` and `auid` live on the other record and MITRE's `UnusualServiceAccounts` knob cannot be applied inside this selection — sssd's own daemons cannot be excluded here. MITRE's `SecretsAccessThreshold` knob is a frequency test, which lib/sigma has no aggregation or timeframe to express, so this fires on the first access rather than on an unusual rate. It deliberately overlaps the T1003.005 rule in this corpus, which matches `/var/lib/sss/secrets` on a Linux process_creation command line: that rule sees the path an operator typed, this one sees the file actually opened, so each catches what the other structurally misses — a reader invoked with a bare filename or through a runtime-built path leaves nothing on a command line, and a process that never opens the file leaves no PATH record. The brief's other legs were not attempted: the Windows Security leg is scoped to EventID 4672 and 4634, neither of which carries a ticket encryption type, ticket options or a TGT/TGS distinction, so the analytic's stated discriminators cannot be written against it, and its Sysmon Process Access leg reduces to an LSASS handle with dump rights, already published in this corpus under T1003.001 with no field able to separate ticket extraction from any other credential dump. The macOS leg AN1445 is unifiedlog prose with no standardised Sigma field names. Prerequisite: auditd watches nothing under /var/lib/sss by default, so this rule returns zero rows until a watch such as `-w /var/lib/sss/secrets/ -p rwa -k kerberos_secrets` is loaded, and zero rows reads as quiet when it actually means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0522, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 3 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Splunk · SPL

Run this as a search.

index=* ((type="PATH" AND name="/var/lib/sss/secrets/*") OR (type="PATH" AND (name="*secrets.ldb" OR name="*secrets.mkey")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((TO_LOWER(type) == "path" AND TO_LOWER(name) LIKE "/var/lib/sss/secrets/*") OR (TO_LOWER(type) == "path" AND (TO_LOWER(name) LIKE "*secrets.ldb" OR TO_LOWER(name) LIKE "*secrets.mkey")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,linux,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <!-- 2 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)^/var/lib/sss/secrets/</field>    <description>SSSD Kerberos secrets database opened on Linux (1/2)</description>    <mitre>      <id>T1558</id>    </mitre>  </rule>   <rule id="100001" level="5">    <!-- Set <if_sid> to the decoder/base rule for linux so this only evaluates relevant events. -->    <field name="type" type="pcre2">(?i)^PATH$</field>    <field name="name" type="pcre2">(?i)(secrets\.ldb$|secrets\.mkey$)</field>    <description>SSSD Kerberos secrets database opened on Linux (2/2)</description>    <mitre>      <id>T1558</id>    </mitre>  </rule></group>

Sentinel · KQL

Run this as a search.

Sentinel cannot express this construct. No Sentinel table is modelled for this logsource ({"product":"linux","service":"auditd"}), so there is nothing honest to query. Pick a logsource this translator maps, or write the KQL by hand. The Sigma source is on the first tab, unchanged.

At a glance

Logsource: auditd / linux
Level: low
Category: kerberos_ticket_abuse
Sigma status: experimental
Backends: 3 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 78d709f5-f594-4548-8643-c74c5325a299

ATT&CKT1558

T1558Steal or Forge Kerberos Tickets

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonkerberos ticket abuse

kerberos ticket abuseAI draft — unreviewed

01 · What this rule detects

A process opening the SSSD secrets store on a domain-joined Linux host — /var/lib/sss/secrets/secrets.ldb and its master key .secrets.mkey. That database holds the cached Kerberos key material an adversary needs before any ticket can be reused or forged, so this is an upstream observable rather than a ticket-level one. It is the only leg of DET0522 whose observable survives as a single event. The Windows leg (AN1443) is scoped to Security EventID 4672 and 4634, neither of which carries a ticket encryption type, ticket options, or a TGT/TGS distinction, so the analytic's own discriminators cannot be written against it; its Process Access leg reduces to an LSASS handle already covered under T1003.001. The macOS leg is unifiedlog prose with no standardised field names.

02 · Telemetry you need

linux/auditd, taken verbatim from AN1444 — and a watch, which is the prerequisite that decides whether this rule works at all. auditd watches nothing under /var/lib/sss by default. Until something like -w /var/lib/sss/secrets/ -p rwa -k kerberos_secrets is loaded, the rule returns zero rows because nothing is being collected, not because nothing happened. That is the failure mode this corpus exists to warn about: silence that reads as quiet when it means blind.

03 · How the logic works

Two selections, OR-ed via 1 of selection*, both pinned to type: 'PATH'. selection_path is name|startswith: '/var/lib/sss/secrets/'. selection_name is name|endswith on secrets.ldb and secrets.mkey. The split exists because auditd records name= exactly as it was handed to the syscall — a cp run from inside the directory logs a bare secrets.ldb with no directory component, which the absolute-path gate cannot see. The important structural limit: auditd emits PATH and SYSCALL as separate records for one event. The reading process's exe, uid, and auid live on the SYSCALL record, so no selection here can reach them — which means sssd's own daemons cannot be excluded inside the rule. This deliberately overlaps the T1003.005 rule in this corpus, which matches /var/lib/sss/secrets on a Linux process_creation command line. That rule sees the path an operator typed; this one sees the file actually opened. Each catches what the other structurally misses.

04 · Common false positives

Very. sssd_be, sssd_nss, and the sssd_secrets responder open both files as their normal function on every cached lookup and every offline authentication — and, per the record-split above, cannot be filtered out here. Under a watch that includes r this is the overwhelming majority of matches on any joined host, which is exactly why the level is low. Beyond that: realm join, adcli, and ipa-client-install write the store during enrolment, so every reimaged machine produces a burst; sssd package upgrades and systemctl restart sssd reopen both files; backup and integrity tooling that walks /var/lib (rsync, Bacula, AIDE, Tripwire) reads them on schedule; and an admin running sssctl reads the database directly.

05 · Detection maturity

tier_1: Lowest tier, and it stays there until run against real data. Nothing here has been executed against a log line — the noise ranking above is argued, not measured.

Tuning & false positivesexperimental · 5 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Start with the watch itself: dropping r and watching only wa removes most of the daemon noise at the cost of missing pure reads. MITRE names the UnusualServiceAccounts knob — baseline the accounts that normally touch Kerberos material — but applying it requires joining the PATH record to its SYSCALL sibling on the audit event ID, which is pipeline work, not selection work. MITRE's SecretsAccessThreshold knob is a frequency test; lib/sigma has no aggregation or timeframe, so this fires on the first access rather than on an unusual rate.

Declared by the author

SSSD's own daemons. sssd_be, sssd_nss and the sssd_secrets responder open secrets.ldb and .secrets.mkey as their normal function on every cached credential lookup and every offline authentication, and because the accessing process lives on the SYSCALL record rather than the PATH record it cannot be excluded from this selection. Under a watch that includes r this is the overwhelming majority of matches on any domain-joined host, which is why the level is low.
Enrolment and re-enrolment tooling: realm join, adcli, ipa-client-install and authselect write the SSSD secrets store as part of joining or rejoining the host to a directory, and every rebuilt or reimaged machine produces a burst of matching records.
Package upgrades and service restarts. Updating the sssd package replaces or reopens the database from its postinst scripts, and systemctl restart sssd reopens both files on every start.
Backup, imaging and compliance agents that walk /var/lib in full — rsync, tar, Bacula, Veeam and BorgBackup all read the secrets store on a scheduled sweep, as do file integrity monitors such as AIDE and Tripwire when they rebuild their baseline.
An administrator running sssctl or SSSD's own troubleshooting steps, which read the secrets database directly when diagnosing an offline-authentication or cached-credential problem.

Noise check0 of 5 fired

Fires on none of the 5 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 5 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1558, evaluated against their — events.

Share this rule

/u/siemphony/78d709f5-f594-4548-8643-c74c5325a299

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

SSSD Kerberos secrets database opened on Linux

The detection

detection.yml

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Sentinel · KQL

Community

Verdicts from engineers who deployed it