Detection rules › Panther

Databricks User Account Created

Status
Experimental
Severity
informational
Group by
requestParams.targetUserName
Log types
Databricks.Audit
Tags
Databricks, Persistence
Reference
https://github.com/databricks-solutions/cybersec-workspace-detection-app/tree/main/base/detections/behavioral
Source
github.com/panther-labs/panther-analysis

Detects creation of new user accounts in Databricks. Account creation may be part of normal onboarding or could indicate an attacker establishing persistence.

MITRE ATT&CK coverage

TacticTechniques
PersistenceT1136 Create Account

Rule body yaml

AnalysisType: rule
Filename: databricks_user_account_created.py
RuleID: "Databricks.Audit.UserAccountCreated"
DisplayName: "Databricks User Account Created"
Enabled: true
Status: Experimental
LogTypes:
  - Databricks.Audit
Tags:
  - Databricks
  - Persistence
Reports:
  MITRE ATT&CK:
    - TA0003:T1136 # Create Account
Severity: Info
Description: >
  Detects creation of new user accounts in Databricks. Account creation may be part of
  normal onboarding or could indicate an attacker establishing persistence.
Runbook: |
  1. Verify the account creation was part of an approved onboarding workflow
  2. Check if the new account was immediately granted elevated privileges
  3. Review the actor who created the account
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/tree/main/base/detections/behavioral
Tests:
  - Name: User Created via createUser
    ExpectedResult: true
    Log:
      serviceName: "accounts"
      actionName: "createUser"
      userIdentity:
        email: "admin@example.com"
      requestParams:
        targetUserName: "newuser@example.com"
      response:
        statusCode: 200


  - Name: Different Service - Should Not Alert
    ExpectedResult: false
    Log:
      serviceName: "workspace"
      actionName: "createUser"
      userIdentity:
        email: "admin@example.com"

  - Name: Different Action - Should Not Alert
    ExpectedResult: false
    Log:
      serviceName: "accounts"
      actionName: "deleteUser"
      userIdentity:
        email: "admin@example.com"

Detection logic

Condition

serviceName eq "accounts"
actionName in ["createUser", "addUser"]

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
actionNamein
  • addUser
  • createUser
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