Detection rules › Panther
Databricks Group Deleted
Detects group deletions in Databricks accounts. While often part of normal cleanup processes, unauthorized group deletions could indicate access control dismantling. Successful deletions are elevated to HIGH severity.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Impact | T1531 Account Access Removal |
Rule body yaml
AnalysisType: rule
Filename: databricks_group_deleted.py
RuleID: "Databricks.Audit.GroupDeleted"
DisplayName: "Databricks Group Deleted"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Impact
Reports:
MITRE ATT&CK:
- TA0040:T1531 # Account Access Removal
Severity: Low
Description: >
Detects group deletions in Databricks accounts. While often part of normal cleanup processes,
unauthorized group deletions could indicate access control dismantling. Successful deletions
are elevated to HIGH severity.
Runbook: |
1. Query audit logs for all members who were in this group in the 24 hours before deletion
2. Check if this group had admin privileges or access to sensitive resources based on past 30 days of activity
3. Find all group deletions by this actor in the past 30 days to identify bulk deletion patterns
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/blob/main/base/detections/event-based/group_deleted.py
Tests:
- Name: Successful Group Deletion
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "removeGroup"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
targetGroupId: "group-123"
response:
statusCode: 200
- Name: Group Deletion from Permission Assignment
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "removeGroup"
userIdentity:
email: "admin@example.com"
sourceIPAddress: "198.51.100.1"
requestParams:
endpoint: "permissionAssignment"
targetUserName: "developers-group"
response:
statusCode: 200
- Name: Failed Group Deletion
ExpectedResult: true
Log:
timestamp: 1234567890000
serviceName: "accounts"
actionName: "removeGroup"
userIdentity:
email: "admin@example.com"
requestParams:
targetGroupId: "group-456"
response:
statusCode: 403
- Name: Wrong Service
ExpectedResult: false
Log:
timestamp: 1234567890000
serviceName: "workspace"
actionName: "removeGroup"
userIdentity:
email: "admin@example.com"
Detection logic
Condition
not (userAgent contains "Databricks-Service/driver" or userAgent contains "Databricks-Runtime" or userAgent contains "Delta-Sharing-SparkStructuredStreaming" or userAgent contains "RawDBHttpClient" or userAgent contains "mlflow-python" or userAgent contains "obsSDK-scala" or userAgent contains "wsfs" or userAgent contains "feature-store" or requestParams.path contains "/telemetry" or requestParams.path contains "/delta-commit" or requestParams.path contains "/health" or requestParams.path contains "/metrics" or requestParams.path contains "/status" or userIdentity.email regex_match "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}")
serviceName eq "accounts"
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 |
|---|---|---|
requestParams.path | contains | /delta-commit |
requestParams.path | contains | /health |
requestParams.path | contains | /metrics |
requestParams.path | contains | /status |
requestParams.path | contains | /telemetry |
userAgent | contains | Databricks-Runtime |
userAgent | contains | Databricks-Service/driver |
userAgent | contains | Delta-Sharing-SparkStructuredStreaming |
userAgent | contains | RawDBHttpClient |
userAgent | contains | feature-store |
userAgent | contains | mlflow-python |
userAgent | contains | obsSDK-scala |
userAgent | contains | wsfs |
userIdentity.email | regex_match | [0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12} |
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 |
|---|---|---|
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 |