Detection rules › Panther
Databricks Account Admin Privileged Role Assignment
Detects when account-level admin privileges are granted in Databricks through direct role assignments or administrative group membership. Account admins have extensive control across all workspaces and should be carefully monitored. Successful grants are elevated to HIGH severity.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1098 Account Manipulation, T1136 Create Account |
| Privilege Escalation | T1098 Account Manipulation |
Rule body yaml
AnalysisType: rule
Filename: databricks_account_admin_privileged_role_assignment.py
RuleID: "Databricks.Audit.AccountAdminPrivilegedRoleAssignment"
DisplayName: "Databricks Account Admin Privileged Role Assignment"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Privilege Escalation
- Persistence
Reports:
MITRE ATT&CK:
- TA0004:T1098 # Account Manipulation
- TA0003:T1136 # Create Account
Severity: Medium
Description: >
Detects when account-level admin privileges are granted in Databricks through direct role
assignments or administrative group membership. Account admins have extensive control across
all workspaces and should be carefully monitored. Successful grants are elevated to HIGH severity.
Runbook: |
1. Query audit logs for all account-level administrative actions by the target principal in the 24 hours after this privilege grant
2. Check if the target principal accessed multiple workspaces or performed bulk operations in the 6 hours after receiving admin rights
3. Find all account admin grants in the past 90 days to identify unusual patterns or privilege escalation chains
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/blob/main/base/detections/event-based/account_admin_privileged_role_assignment.py
SummaryAttributes:
- actor
- target_principal
- principal_type
Tests:
- Name: Set Account Admin Success
ExpectedResult: true
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "setAccountAdmin"
accountId: "12345678-1234-1234-1234-123456789012"
userIdentity:
email: "superadmin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
targetUserName: "newadmin@example.com"
response:
statusCode: 200
- Name: Change Account Owner
ExpectedResult: true
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "changeAccountOwner"
userIdentity:
email: "owner@example.com"
requestParams:
targetUserName: "newowner@example.com"
response:
statusCode: 200
- Name: Add to Admin Group
ExpectedResult: true
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "addPrincipalToGroup"
userIdentity:
email: "admin@example.com"
requestParams:
principal: "user@example.com"
targetGroupName: "account-admins"
response:
statusCode: 200
- Name: Failed Admin Grant
ExpectedResult: true
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "setAccountAdmin"
userIdentity:
email: "attacker@example.com"
requestParams:
targetUserName: "attacker@example.com"
response:
statusCode: 403
- Name: Workspace-Level Admin Grant
ExpectedResult: false
Log:
timestamp: 1234567890000
auditLevel: "WORKSPACE_LEVEL"
serviceName: "accounts"
actionName: "setAdmin"
userIdentity:
email: "admin@example.com"
requestParams:
targetUserName: "user@example.com"
- Name: Remove Admin Should Not Alert
ExpectedResult: false
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "removeAdmin"
userIdentity:
email: "admin@example.com"
requestParams:
targetUserName: "user@example.com"
response:
statusCode: 200
- Name: Remove From Admin Group Should Not Alert
ExpectedResult: false
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "removePrincipalFromGroup"
userIdentity:
email: "admin@example.com"
requestParams:
principal: "user@example.com"
targetGroupName: "account-admins"
response:
statusCode: 200
- Name: Non-Admin Group
ExpectedResult: false
Log:
timestamp: 1234567890000
auditLevel: "ACCOUNT_LEVEL"
serviceName: "accounts"
actionName: "addPrincipalToGroup"
userIdentity:
email: "admin@example.com"
requestParams:
principal: "user@example.com"
targetGroupName: "developers"
Detection logic
Condition
auditLevel eq "ACCOUNT_LEVEL"
actionName not in ["removeAdmin", "removePrincipalFromGroup"]
This rule also runs imperative logic the parser cannot express as a filter; the conditions above are the structured part it could extract.
Exclusions
Top-level NOT(...) conjuncts: predicates this rule actively suppresses.
| Field | Kind | Excluded values |
|---|---|---|
actionName | in | removeAdmin, removePrincipalFromGroup |
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 |
|---|---|---|
auditLevel | 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 |