Detection rules › Panther

Enabled Zendesk Support to Assume Users

Severity
medium
Log types
Zendesk.Audit
Tags
Zendesk, Lateral Movement:Use Alternate Authentication Material
Reference
https://support.zendesk.com/hc/en-us/articles/4408894200474-Assuming-end-users#:~:text=In%20Support%2C%20click%20the%20Customers,user%20in%20the%20information%20dialog
Source
github.com/panther-labs/panther-analysis

User enabled or disabled zendesk support user assumption.

MITRE ATT&CK coverage

TacticTechniques
Lateral MovementT1550 Use Alternate Authentication Material

Rule body yaml

AnalysisType: rule
Filename: zendesk_user_assumption.py
RuleID: "Zendesk.UserAssumption"
DisplayName: "Enabled Zendesk Support to Assume Users"
Enabled: true
LogTypes:
  - Zendesk.Audit
Tags:
  - Zendesk
  - Lateral Movement:Use Alternate Authentication Material
Reports:
  MITRE ATT&CK:
    - TA0008:T1550
Severity: Medium
Description: User enabled or disabled zendesk support user assumption.
Runbook: >
  Investigate whether allowing zendesk support to assume users is necessary. If not, disable the feature.
Reference: https://support.zendesk.com/hc/en-us/articles/4408894200474-Assuming-end-users#:~:text=In%20Support%2C%20click%20the%20Customers,user%20in%20the%20information%20dialog
SummaryAttributes:
  - p_any_ip_addresses
Tests:
  - Name: User assumption settings changed
    ExpectedResult: true
    Log:
      {
        "url": "https://myzendek.zendesk.com/api/v2/audit_logs/111222333444.json",
        "id": 123456789123,
        "action_label": "Updated",
        "actor_id": 123,
        "actor_name": "John Doe",
        "source_id": 123,
        "source_type": "account_setting",
        "source_label": "Account Assumption",
        "action": "update",
        "change_description": "Changed",
        "ip_address": "127.0.0.1",
        "created_at": "2021-05-28T18:39:50Z",
        "p_log_type": "Zendesk.Audit",
      }
  - Name: Zendesk - Credit Card Redaction On
    ExpectedResult: false
    Log:
      {
        "url": "https://myzendek.zendesk.com/api/v2/audit_logs/111222333444.json",
        "id": 123456789123,
        "action_label": "Updated",
        "actor_id": 123,
        "actor_name": "John Doe",
        "source_id": 123,
        "source_type": "account_setting",
        "source_label": "Credit Card Redaction",
        "action": "create",
        "change_description": "Enabled",
        "ip_address": "127.0.0.1",
        "created_at": "2021-05-28T18:39:50Z",
        "p_log_type": "Zendesk.Audit",
      }

Detection logic

Condition

source_type eq "account_setting"
action in ["create", "update"]
source_label in ["account assumption", "assumption duration"]

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
actionin
  • create
  • update
source_labelin
  • account assumption
  • assumption duration
source_typeeq
  • account_setting

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
actor_user