Detection rules › Panther

Databricks User Account Deleted

Status
Experimental
Severity
low
Group by
requestParams.targetUserName
Log types
Databricks.Audit
Tags
Databricks, Impact
Reference
https://github.com/databricks-solutions/cybersec-workspace-detection-app/blob/main/base/detections/event-based/user_account_deleted.py
Source
github.com/panther-labs/panther-analysis

Detects user account deletions in Databricks. While often part of normal offboarding processes, unauthorized deletions could indicate malicious activity or insider threats. Successful deletions are elevated to HIGH severity.

MITRE ATT&CK coverage

TacticTechniques
ImpactT1531 Account Access Removal

Rule body yaml

AnalysisType: rule
Filename: databricks_user_account_deleted.py
RuleID: "Databricks.Audit.UserAccountDeleted"
DisplayName: "Databricks User Account Deleted"
Enabled: true
Status: Experimental
LogTypes:
  - Databricks.Audit
Tags:
  - Databricks
  - Impact
Reports:
  MITRE ATT&CK:
    - TA0040:T1531 # Account Access Removal
Severity: Low
Description: >
  Detects user account deletions in Databricks. While often part of normal offboarding processes,
  unauthorized deletions could indicate malicious activity or insider threats. Successful deletions
  are elevated to HIGH severity.
Runbook: |
  1. Query audit logs for all actions performed by the deleted user (requestParams.targetUserName) in the 48 hours before deletion
  2. Check if there were any privilege escalation or suspicious actions by this user in the 7 days before deletion
  3. Find all user 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/user_account_deleted.py
Tests:
  - Name: Successful User Deletion
    ExpectedResult: true
    Log:
      timestamp: 1234567890000
      serviceName: "accounts"
      actionName: "delete"
      userIdentity:
        email: "admin@example.com"
      sourceIPAddress: "198.51.100.1"
      requestParams:
        targetUserName: "user@example.com"
        endpoint: "/users"
      response:
        statusCode: 200
  - Name: Failed User Deletion
    ExpectedResult: true
    Log:
      timestamp: 1234567890000
      serviceName: "accounts"
      actionName: "delete"
      userIdentity:
        email: "admin@example.com"
      sourceIPAddress: "198.51.100.1"
      requestParams:
        targetUserName: "user@example.com"
        endpoint: "/users"
      response:
        statusCode: 403
  - Name: Wrong Service
    ExpectedResult: false
    Log:
      timestamp: 1234567890000
      serviceName: "workspace"
      actionName: "delete"
      userIdentity:
        email: "admin@example.com"
  - Name: Delete Without User Context
    ExpectedResult: false
    Log:
      timestamp: 1234567890000
      serviceName: "accounts"
      actionName: "delete"
      userIdentity:
        email: "admin@example.com"
      requestParams:
        endpoint: "/servicePrincipals"
      response:
        statusCode: 200
  - Name: Different Action
    ExpectedResult: false
    Log:
      timestamp: 1234567890000
      serviceName: "accounts"
      actionName: "create"
      userIdentity:
        email: "admin@example.com"

Detection logic

Condition

serviceName eq "accounts"
actionName eq "delete"
requestParams.targetUserName is_not_null or requestParams.endpoint contains "/users/" or requestParams.endpoint starts_with "users"

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.

FieldKindValues
actionNameeq
  • delete
requestParams.endpointcontains
  • /users/
requestParams.endpointstarts_with
  • users
requestParams.targetUserNameis_not_null
  • (no value, null check)
serviceNameeq
  • accounts

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.

FieldSource
targetUserNamerequestParams.targetUserName
emailuserIdentity.email