Detection rules › Panther
Databricks Data Movement with Explicit Credentials
Detects creation or modification of storage credentials, connections, and external locations that could facilitate data exfiltration. These operations establish direct paths to external storage and may indicate data movement preparation. Mount point creation is covered separately by Databricks.Audit.MountPointCreation.
MITRE ATT&CK coverage
| Tactic | Techniques |
|---|---|
| Exfiltration | T1537 Transfer Data to Cloud Account |
Rule body yaml
AnalysisType: rule
Filename: databricks_data_movement_explicit_credentials.py
RuleID: "Databricks.Audit.DataMovementExplicitCredentials"
DisplayName: "Databricks Data Movement with Explicit Credentials"
Enabled: true
Status: Experimental
LogTypes:
- Databricks.Audit
Tags:
- Databricks
- Exfiltration
Reports:
MITRE ATT&CK:
- TA0010:T1537 # Transfer Data to Cloud Account
Severity: Info
Description: >
Detects creation or modification of storage credentials, connections, and external
locations that could facilitate data exfiltration. These operations establish direct
paths to external storage and may indicate data movement preparation. Mount point
creation is covered separately by Databricks.Audit.MountPointCreation.
Runbook: |
1. Verify the credential/connection creation was part of an approved workflow
2. Check the target storage location for sensitivity
3. Monitor for subsequent data access through the new credential
Reference: https://github.com/databricks-solutions/cybersec-workspace-detection-app/tree/main/base/detections/behavioral
Tests:
- Name: Storage Credential Created
ExpectedResult: true
Log:
serviceName: "unityCatalog"
actionName: "createStorageCredential"
userIdentity:
email: "admin@example.com"
requestParams:
name: "external-s3-cred"
response:
statusCode: 200
- Name: Connection Updated
ExpectedResult: true
Log:
serviceName: "unityCatalog"
actionName: "updateConnection"
userIdentity:
email: "admin@example.com"
requestParams:
name: "snowflake-conn"
response:
statusCode: 200
- Name: Mount Action - Excluded (covered by separate rule)
ExpectedResult: false
Log:
serviceName: "dbfs"
actionName: "mount"
userIdentity:
email: "user@example.com"
requestParams:
mountPoint: "/mnt/data"
- Name: Different Action - Should Not Alert
ExpectedResult: false
Log:
serviceName: "unityCatalog"
actionName: "getStorageCredential"
userIdentity:
email: "user@example.com"
Detection logic
Condition
actionName in ["mount", "createStorageCredential", "updateStorageCredential", "createConnection", "updateConnection"]
actionName ne "mount"
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 | in |
|
actionName | ne |
|
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 |
|---|---|
actionName | |
workspaceId | |
email | userIdentity.email |