Detection rules › Panther

Databricks Access to Multiple Workspaces

Status
Experimental
Severity
medium
Group by
userIdentity.email
Log types
Databricks.Audit
Tags
Databricks, Lateral Movement, Reconnaissance
Reference
https://github.com/andyweaves/system-tables-audit-logs/blob/main/resources/queries_and_alerts.json
Source
github.com/panther-labs/panther-analysis

Detects users accessing 5 or more distinct workspaces within 24 hours, which may indicate lateral movement, reconnaissance, or compromised credentials.

MITRE ATT&CK coverage

TacticTechniques
Lateral MovementT1021 Remote Services

Rule body yaml

AnalysisType: rule
Filename: databricks_access_to_multiple_workspaces.py
RuleID: "Databricks.Audit.AccessToMultipleWorkspaces"
DisplayName: "Databricks Access to Multiple Workspaces"
Enabled: true
Status: Experimental
LogTypes:
  - Databricks.Audit
Tags:
  - Databricks
  - Lateral Movement
  - Reconnaissance
Reports:
  MITRE ATT&CK:
    - TA0008:T1021 # Remote Services
Severity: Medium
Threshold: 5
DedupPeriodMinutes: 1440
Description: >
  Detects users accessing 5 or more distinct workspaces within 24 hours, which may indicate
  lateral movement, reconnaissance, or compromised credentials.
Runbook: |
  1. Query audit logs for all workspace access by this user in the past 7 days to establish normal patterns
  2. Check if the user performed unusual actions (data downloads, permission changes) across multiple workspaces
  3. Find all users accessing multiple workspaces in the past 30 days to establish baseline
Reference: https://github.com/andyweaves/system-tables-audit-logs/blob/main/resources/queries_and_alerts.json
SummaryAttributes:
  - actor
Tests:
  - Name: Workspace Access
    ExpectedResult: true
    Log:
      timestamp: 1704067200000
      serviceName: "accounts"
      actionName: "login"
      workspaceId: "1234567890123456"
      userIdentity:
        email: "user@example.com"
      response:
        statusCode: 200
  - Name: System User
    ExpectedResult: false
    Log:
      timestamp: 1704067200000
      serviceName: "accounts"
      actionName: "login"
      workspaceId: "1234567890123456"
      userIdentity:
        email: "System-User"

Detection logic

Condition

not (userIdentity.email in "System-User" or userIdentity.email in ["", "unknown"])
workspaceId is_not_null

Exclusions

Top-level NOT(...) conjuncts: predicates this rule actively suppresses.

FieldKindExcluded values
userIdentity.emaileqSystem-User
userIdentity.emailinunknown

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
workspaceIdis_not_null
  • (no value, null check)

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
emailuserIdentity.email