Detection rules › Panther
Databricks User Password Changed
Detects password change events on Databricks accounts. May indicate legitimate password rotation or an unauthorized reset following account compromise.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1098 Account Manipulation |
| Privilege Escalation | T1098 Account Manipulation |
Rule body yaml
AnalysisType: rule
Filename: databricks_user_password_changed.py
RuleID: "Databricks.Audit.UserPasswordChanged"
DisplayName: "Databricks User Password Changed"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Credential Access
Reports:
MITRE ATT&CK:
- TA0006:T1098 # Account Manipulation
Severity: Info
Description: >
Detects password change events on Databricks accounts. May indicate legitimate
password rotation or an unauthorized reset following account compromise.
Runbook: |
1. Verify the password change was initiated by the legitimate account owner
2. Check for preceding suspicious activity (failed logins, MFA changes)
3. If unauthorized, force password reset and revoke active sessions
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/tree/main/base/detections/behavioral
Tests:
- Name: Password Changed Successfully
ExpectedResult: true
Log:
serviceName: "accounts"
actionName: "changePassword"
userIdentity:
email: "user@example.com"
response:
statusCode: 200
- Name: Password Change Failed
ExpectedResult: true
Log:
serviceName: "accounts"
actionName: "changePassword"
userIdentity:
email: "user@example.com"
response:
statusCode: 403
- Name: Different Service - Should Not Alert
ExpectedResult: false
Log:
serviceName: "workspace"
actionName: "changePassword"
userIdentity:
email: "user@example.com"
- Name: Different Action - Should Not Alert
ExpectedResult: false
Log:
serviceName: "accounts"
actionName: "login"
userIdentity:
email: "user@example.com"
Detection logic
Condition
serviceName eq "accounts"
actionName eq "changePassword"
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 |
|
serviceName | 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 |