Detection rules › Panther
Databricks User Role Modified
Detects when user roles are modified or users are added to administrative groups in Databricks. This is often legitimate administrative activity but should be monitored for unauthorized changes.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Privilege Escalation | T1098 Account Manipulation |
Rule body yaml
AnalysisType: rule
Filename: databricks_user_role_modified.py
RuleID: "Databricks.Audit.UserRoleModified"
DisplayName: "Databricks User Role Modified"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Privilege Escalation
Reports:
MITRE ATT&CK:
- TA0004:T1098 # Account Manipulation
Severity: Info
Description: >
Detects when user roles are modified or users are added to administrative groups in Databricks.
This is often legitimate administrative activity but should be monitored for unauthorized changes.
Runbook: |
1. Query audit logs for all role modifications by the actor (userIdentity.email) in the 24 hours before and after this change
2. Check if the target user has performed new actions using the modified role in the 6 hours after the change
3. Find all role modifications for this target user in the past 90 days to establish baseline
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/blob/main/base/detections/event-based/user_role_modified.py
Tests:
- Name: User Added to Admin Group
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "addUserToAdminGroup"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
targetUserName: "user@example.com"
targetGroupName: "admins"
- Name: User Role Modified
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "modifyUserRole"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
targetUserName: "user@example.com"
role: "workspace_admin"
- Name: Different Service
ExpectedResult: false
Log:
timestamp: 1234567890000
serviceName: "workspace"
actionName: "addUserToAdminGroup"
userIdentity:
email: "admin@example.com"
- Name: Unrelated Action
ExpectedResult: false
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "login"
userIdentity:
email: "user@example.com"
Detection logic
Condition
serviceName eq "accounts"
actionName in ["addUserToAdminGroup", "modifyUserRole"]
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 | in |
|
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 |
|---|---|
actionName | |
email | userIdentity.email |