Detection rules › Panther

Slack Primary Owner Transferred

Severity
critical
Log types
Slack.AuditLogs
Tags
Slack, Defense Evasion, Persistence, Account Manipulation, Impact, Account Access Removal, Privilege Escalation
Reference
https://slack.com/intl/en-gb/help/articles/204401633-Transfer-ownership-of-a-workspace-or-org
Source
github.com/panther-labs/panther-analysis

Detects Slack Primary Owner transfers, representing the highest administrative privilege change with absolute control over workspace settings, security, billing, and data access. Primary Owners can add/remove all admins, delete entire workspaces, and transfer ownership. Unauthorized transfers indicate account compromise, insider threats, or hostile takeovers that could lead to permanent data loss or complete security control loss.

MITRE ATT&CK coverage

Rule body yaml

AnalysisType: rule
Filename: slack_service_owner_transferred.py
RuleID: "Slack.AuditLogs.ServiceOwnerTransferred"
DisplayName: "Slack Primary Owner Transferred"
Enabled: true
LogTypes:
  - Slack.AuditLogs
Tags:
  - Slack
  - Defense Evasion
  - Persistence
  - Account Manipulation
  - Impact
  - Account Access Removal
  - Privilege Escalation
Reports:
  MITRE ATT&CK:
    - TA0004:T1078.004
    - TA0003:T1098
    - TA0040:T1531
Severity: Critical
Description: >
  Detects Slack Primary Owner transfers, representing the highest administrative privilege change with absolute control over workspace settings, security, billing, and data access. Primary Owners can add/remove all admins, delete entire workspaces, and transfer ownership. Unauthorized transfers indicate account compromise, insider threats, or hostile takeovers that could lead to permanent data loss or complete security control loss.
Reference: https://slack.com/intl/en-gb/help/articles/204401633-Transfer-ownership-of-a-workspace-or-org
Runbook: |
  1. Query Slack audit logs for both actor.user.email and entity.user.email in the 30 days before the ownership transfer to identify suspicious authentication patterns, logins from unusual locations, or unexpected administrative actions indicating account compromise
  2. Check if entity.user.email has made any concerning administrative changes since receiving ownership such as removing administrators, disabling security controls, adding unknown users, or creating API tokens
  3. Review the context.ip_address and user agent from where the transfer was initiated to determine if it matches the previous Primary Owner's normal access patterns and geographic location
DedupPeriodMinutes: 60
Threshold: 1
SummaryAttributes:
  - p_any_ip_addresses
  - p_any_emails
Tests:
  - Name: Service Owner Transferred
    ExpectedResult: true
    Log:
      {
        "action": "service_owner_transferred",
        "actor":
          {
            "type": "user",
            "user":
              {
                "email": "user@example.com",
                "id": "A012B3CDEFG",
                "name": "username",
                "team": "T01234N56GB",
              },
          },
        "context":
          {
            "ip_address": "1.2.3.4",
            "location":
              {
                "domain": "test-workspace",
                "id": "T01234N56GB",
                "name": "test-workspace",
                "type": "workspace",
              },
            "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36",
          },
      }
  - Name: User Logout
    ExpectedResult: false
    Log:
      {
        "action": "user_logout",
        "actor":
          {
            "type": "user",
            "user":
              {
                "email": "user@example.com",
                "id": "W012J3FEWAU",
                "name": "primary-owner",
                "team": "T01234N56GB",
              },
          },
        "context":
          {
            "ip_address": "1.2.3.4",
            "location":
              {
                "domain": "test-workspace-1",
                "id": "T01234N56GB",
                "name": "test-workspace-1",
                "type": "workspace",
              },
            "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36",
          },
        "date_create": "2022-07-28 15:22:32",
        "entity":
          {
            "type": "user",
            "user":
              {
                "email": "user@example.com",
                "id": "W012J3FEWAU",
                "name": "primary-owner",
                "team": "T01234N56GB",
              },
          },
        "id": "72cac009-9eb3-4dde-bac6-ee49a32a1789",
      }

Detection logic

Condition

action eq "service_owner_transferred"

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
actioneq
  • service_owner_transferred

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
actor-nameactor.user.name
actor-emailactor.user.email
actor-ipcontext.ip_address
user-agentcontext.ua
domaincontext.location.domain
emailentity.user.email