Detection rules › Panther
Databricks Repeated Access to Secrets
Detects repeated secret access (≥10 times in 60 minutes) which may indicate credential harvesting or unauthorized secret enumeration.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Credential Access | T1555 Credentials from Password Stores |
Rule body yaml
AnalysisType: rule
Filename: databricks_repeated_access_to_secrets.py
RuleID: "Databricks.Audit.RepeatedAccessToSecrets"
DisplayName: "Databricks Repeated Access to Secrets"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Credential Access
- Collection
Reports:
MITRE ATT&CK:
- TA0006:T1555 # Credentials from Password Stores
Severity: Medium
Threshold: 10
DedupPeriodMinutes: 60
Description: >
Detects repeated secret access (≥10 times in 60 minutes) which may indicate credential
harvesting or unauthorized secret enumeration.
Runbook: |
1. Query audit logs for all secret access by this user in the past 24 hours to identify patterns
2. Check if the accessed secrets were used in API calls or notebook execution in the 6 hours after access
3. Find all users with high secret access rates in the past 7 days to establish baseline
Reference: https://github.com/andyweaves/system-tables-audit-logs/blob/main/resources/queries_and_alerts.json
SummaryAttributes:
- actor
- secret_scope
Tests:
- Name: Secret Access
ExpectedResult: true
Log:
timestamp: 1704067200000
serviceName: "secrets"
actionName: "getSecret"
userIdentity:
email: "user@example.com"
requestParams:
scope: "production-keys"
key: "api-token"
response:
statusCode: 200
- Name: System User Access
ExpectedResult: false
Log:
timestamp: 1704067200000
serviceName: "secrets"
actionName: "getSecret"
userIdentity:
email: "System-User"
requestParams:
scope: "internal"
key: "config"
Detection logic
Condition
actionName eq "getSecret"
userIdentity.email not in "System-User"
Exclusions
Top-level NOT(...) conjuncts: predicates this rule actively suppresses.
| Field | Kind | Excluded values |
|---|---|---|
userIdentity.email | eq | System-User |
Indicators
Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.
| Field | Kind | Values |
|---|---|---|
actionName | eq |
|
Output fields
Fields the rule emits when it matches. Chronicle authors list these in the outcome block; they appear on the detection and $risk_score drives alerting. Sentinel / Defender XDR rules build them up through project / summarize / extend stages. Sentinel maps these into alert fields via entityMappings and customDetails; Defender XDR custom detections surface them as alert fields directly.
| Field | Source |
|---|---|
email | userIdentity.email |
scope | requestParams.scope |