Detection rules › Panther
Databricks Principal Removed From Group
Detects when principals (users or service principals) are removed from groups in Databricks accounts. This is often legitimate administrative activity but should be monitored for unauthorized membership changes.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Persistence | T1098 Account Manipulation |
Rule body yaml
AnalysisType: rule
Filename: databricks_principal_removed_from_group.py
RuleID: "Databricks.Audit.PrincipalRemovedFromGroup"
DisplayName: "Databricks Principal Removed From Group"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Persistence
Reports:
MITRE ATT&CK:
- TA0003:T1098 # Account Manipulation
Severity: Info
Description: >
Detects when principals (users or service principals) are removed from groups in Databricks accounts.
This is often legitimate administrative activity but should be monitored for unauthorized membership changes.
Runbook: |
1. Query audit logs for all group membership changes by the actor in the 24 hours around this event
2. Check if the removed principal had active sessions or API calls in the 1 hour before removal
3. Find all group membership removals for this group in the past 30 days to identify patterns
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/blob/main/base/detections/event-based/principal_removed_from_group.py
Tests:
- Name: Principal Removed Successfully
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "removePrincipalFromGroup"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
targetUserName: "user@example.com"
targetGroupName: "developers"
response:
statusCode: 200
- Name: Admin Removed from Group
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "removePrincipalFromGroup"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
targetUserName: "power-user@example.com"
targetGroupName: "admins"
response:
statusCode: 200
- Name: Wrong Service Name
ExpectedResult: false
Log:
timestamp: 1234567890000
serviceName: "workspace"
actionName: "removePrincipalFromGroup"
userIdentity:
email: "admin@example.com"
- Name: Different Action
ExpectedResult: false
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "addPrincipalToGroup"
userIdentity:
email: "admin@example.com"
requestParams:
targetUserName: "user@example.com"
targetGroupName: "developers"
Detection logic
Condition
serviceName eq "accounts"
actionName eq "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 |
|---|---|---|
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 |
|---|---|
targetUserName | requestParams.targetUserName |
targetGroupName | requestParams.targetGroupName |
email | userIdentity.email |