Scattered Spider and the Case for Sigma Rule Suites

May 9, 2026 -

You’ve probably heard the name Scattered Spider. They made headlines by breaching MGM Resorts and Caesars Entertainment using nothing more sophisticated than a phone call. No zero-days. No nation-state tooling. Just a convincing voice, a tired help desk employee, and a chain of technique abuse that most organizations weren’t watching for.

Here’s the thing: chasing Scattered Spider specifically isn’t a viable detection strategy. Threat actors rebrand, pivot, and dissolve. Their members move on. What they leave behind, though, is a roadmap.

The techniques Scattered Spider used aren’t theirs. They belong to the broader playbook of financially motivated intrusion groups — and they show up everywhere. MFA fatigue attacks, rogue identity provider registration, legitimate remote access tools repurposed for command and control — these are techniques, not signatures. They’ll outlast any individual threat actor.

That’s the argument for building a Sigma rule suite: a coordinated set of detections that covers a technique cluster, not a single adversary. You’re not hunting Scattered Spider. You’re hunting the behaviors that made them dangerous.

What Is a Sigma Rule Suite? (And Why Should You Care?)

If you’ve written Sigma rules before, you know the temptation: one observable, one rule, done. It feels clean. The problem is that individual behaviors are noisy. A single MFA denial isn’t an attack. An RMM binary running on a workstation might be IT. A password reset is usually just a password reset.

A suite is a set of rules designed together, covering related techniques at different fidelity levels, tagged consistently so that when two or three fire in sequence, your SIEM can surface a correlated story instead of three separate alerts.

Think of it like a cocktail. One ingredient tells you nothing. The combination tells you everything.

This post walks through six high-value Sigma rules built around the Scattered Spider technique cluster — detections that will serve you well regardless of which group comes knocking next.

The Technique Cluster: What We’re Covering

The CISA advisory AA23-320A maps Scattered Spider’s activity to a tight set of MITRE ATT&CK techniques. Here’s the cluster we’re building around:

  • T1621 — Multi-Factor Authentication Request Generation (MFA fatigue)
  • T1556.006 — Modify Authentication Process: Multi-Factor Authentication (rogue device enrollment)
  • T1484.002 — Domain Trust Modification (SSO federation abuse)
  • T1219 — Remote Access Software (rogue RMM tools)
  • T1567.002 — Exfiltration Over Web Service (rclone, cloud storage)
  • T1003.001 — OS Credential Dumping: LSASS Memory

Each rule below targets one technique. Together, they cover a kill chain from initial access through exfiltration. Tag them consistently — we’ll talk about that at the end.

Rule 1: MFA Fatigue — The Denial Storm That Ends in an Accept

Technique: T1621 — Multi-Factor Authentication Request Generation

MFA fatigue (also called push bombing) works by flooding a user with authentication prompts until they accept one — either accidentally or out of frustration. A denial storm alone is noisy. The signal worth chasing is the combination: many denials followed by a successful authentication.

This rule looks for exactly that pattern within a short window. A stream of MFA denials capped by an accept is one of the highest-fidelity indicators of a fatigue attack succeeding.

title: MFA Fatigue - High Denial Volume Followed by Successful Authentication
id: 4a7c2b1e-8f3d-4e5a-b9c0-1d2e3f4a5b6c
status: experimental
description: >
  Detects a pattern consistent with MFA push bombing: multiple MFA denials
  for a single user within a short window, followed by a successful MFA
  authentication. This sequence is a strong indicator of MFA fatigue success.  
references:
  - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
  - https://attack.mitre.org/techniques/T1621/
author: Cyber Mixology
date: 2026-05-09
tags:
  - attack.credential_access
  - attack.t1621
  - social-engineering-intrusion-suite
logsource:
  category: authentication
  product: azure_ad   # Adjust for Okta, Duo, or your IdP of choice
detection:
  selection_deny:
    ResultType: "500121"          # AADSTS500121 = MFA denied by user
    AuthenticationRequirement: "multiFactorAuthentication"
  selection_success:
    ResultType: "0"               # 0 = success
    AuthenticationRequirement: "multiFactorAuthentication"
  timeframe: 10m
  condition: |
    selection_deny
    | count() by UserPrincipalName >= 5
    | selection_success by UserPrincipalName within 10m after selection_deny    
falsepositives:
  - Legitimate user accidentally denied multiple prompts and then authenticated
  - Automated testing or login orchestration tools
level: high

Tuning tip: Start with a threshold of 5 denials. In most environments, legitimate users deny a push once or twice at most. Five is a conservative floor. Raise it if you see legitimate noise; lower it for high-risk accounts.

Rule 2: Rogue MFA Device Enrollment After Password Reset

Technique: T1556.006 — Modify Authentication Process: Multi-Factor Authentication

Once an attacker has reset a victim’s password via social engineering, they move quickly. They enroll their own MFA device so they control the account going forward. The sequence is the tell: an admin-initiated password reset followed immediately by MFA device enrollment from a previously unseen IP.

A new MFA registration is a normal event. A new MFA registration within minutes of a password reset, from an IP that has never appeared on that account, is not.

title: MFA Device Enrollment Immediately Following Admin Password Reset
id: 9e1f3c7a-2b4d-4f8e-a0b1-5c6d7e8f9a0b
status: experimental
description: >
  Detects MFA device registration occurring within a short window after an
  admin-initiated password reset on the same account. This sequence is
  consistent with post-social-engineering account takeover, where an attacker
  resets a victim's password via help desk impersonation and immediately
  registers their own authenticator device.  
references:
  - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
  - https://attack.mitre.org/techniques/T1556/006/
author: Cyber Mixology
date: 2026-05-09
tags:
  - attack.persistence
  - attack.t1556.006
  - social-engineering-intrusion-suite
logsource:
  product: azure_ad
  category: auditlogs
detection:
  password_reset:
    OperationName: "Reset user password"
    InitiatedBy.UserAgent|contains: "admin"   # Distinguish admin-driven resets
  mfa_enrollment:
    OperationName: "User registered security info"
  timeframe: 15m
  condition: password_reset followed by mfa_enrollment where password_reset.TargetResources == mfa_enrollment.TargetResources within 15m
falsepositives:
  - Legitimate new employee onboarding where IT resets password and guides user through MFA setup
  - Helpdesk-assisted recovery sessions with the user present on a call
level: high

Tuning tip: Exclude known onboarding workflows by filtering on user creation date. If the account was created in the last 24 hours, the sequence is expected. If it’s a three-year-old account, it warrants investigation.

Rule 3: Federated Identity Provider Added to SSO Tenant

Technique: T1484.002 — Domain Trust Modification

This is the rule with the best precision-to-noise ratio in the entire suite. Adding a federated identity provider (IdP) to your SSO tenant — Okta, Entra ID, or similar — is an extremely rare administrative action. Scattered Spider used this technique to elevate privileges by injecting a malicious IdP and leveraging account linking to take over privileged accounts.

In most organizations, this happens a handful of times per year, at most. Any unexpected instance deserves immediate investigation.

title: New Federated Identity Provider Added to SSO Tenant
id: b2d4f6a8-c0e2-4f1a-9b3d-5e7f9a1b3c5d
status: stable
description: >
  Detects the addition of a new federated identity provider (SAML or OIDC) to
  an SSO tenant. This is a rare administrative action and has been used by
  threat actors including Scattered Spider to establish persistent privileged
  access via malicious IdP federation and account linking.  
references:
  - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
  - https://attack.mitre.org/techniques/T1484/002/
author: Cyber Mixology
date: 2026-05-09
tags:
  - attack.privilege_escalation
  - attack.t1484.002
  - social-engineering-intrusion-suite
logsource:
  product: okta
  service: system_log
detection:
  selection:
    eventType|startswith:
      - "system.idp.lifecycle.create"
      - "system.idp.lifecycle.activate"
  condition: selection
falsepositives:
  - Legitimate IdP federation projects (new SSO integrations, M&A activity)
  - Sanctioned identity architecture changes
level: critical

Tuning tip: This rule can realistically be set to critical and left untuned in most environments. The false positive rate is very low. Alert on every instance and investigate. If you’re running a known federation project, suppress by the specific admin account during the maintenance window only.

Rule 4: Rogue RMM Tool Executed from User-Writable Path

Technique: T1219 — Remote Access Software

Scattered Spider relied heavily on legitimate remote access tools — ngrok, Screenconnect, Splashtop, Tactical RMM, Fleetdeck, Level.io, and others. These tools are not inherently malicious. That’s the point. They blend in with normal IT activity.

The differentiator is context. Legitimate IT-deployed RMM tools live in managed directories and are pushed via software management systems. Attacker-installed RMM tools show up in Downloads, AppData, or Temp — wherever a user (or a vishing victim) dropped the installer. This rule focuses on that execution path, not the binary name.

title: Remote Access Tool Executed from User-Writable Directory
id: 7f9b1d3e-5a7c-4b8f-8d0e-2f4a6b8c0d2e
status: experimental
description: >
  Detects known remote access and tunneling tool binaries executing from
  user-writable directories (Downloads, AppData, Temp). Legitimate IT-managed
  RMM tools are deployed to managed paths. Execution from user-writable paths
  suggests an attacker or social engineering victim installed the tool manually.  
references:
  - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
  - https://attack.mitre.org/techniques/T1219/
author: Cyber Mixology
date: 2026-05-09
tags:
  - attack.command_and_control
  - attack.t1219
  - social-engineering-intrusion-suite
logsource:
  category: process_creation
  product: windows
detection:
  selection_image:
    Image|endswith:
      - '\ngrok.exe'
      - '\screenconnect.exe'
      - '\connectwisecontrol.exe'
      - '\splashtop.exe'
      - '\tactical.exe'
      - '\fleetdeck.exe'
      - '\level.exe'
      - '\pulseway.exe'
      - '\anydesk.exe'
      - '\teamviewer.exe'
  selection_path:
    Image|contains:
      - '\Users\\'
      - '\AppData\\'
      - '\Downloads\\'
      - '\Temp\\'
      - '\Public\\'
  condition: selection_image and selection_path
falsepositives:
  - Users who self-install legitimate remote support tools with IT approval
  - Developer environments where ngrok is used intentionally
level: medium

Tuning tip: Maintain a software inventory allowlist. If ngrok is approved for developer use, filter on known developer workstation hostnames. The goal is surfacing unsanctioned installs, not blocking a legitimate tool across the board.

Rule 5: rclone Used to Sync Data to External Cloud Storage

Technique: T1567.002 — Exfiltration Over Web Service: Exfiltration to Cloud Storage

rclone is a legitimate, open-source cloud sync tool. It’s also one of the most consistently observed exfiltration utilities across ransomware and extortion group incidents. Legitimate enterprise use of rclone is uncommon enough that any execution warrants attention — especially when cloud provider remote arguments are present in the command line.

This rule focuses on rclone execution with arguments that indicate a cloud sync operation. It pairs well with a network detection for large outbound transfers to cloud provider IP ranges.

title: rclone Executed with Cloud Storage Remote Configuration
id: 3c5e7a9b-1d3f-4a6c-8e0b-4f6a8c0e2f4a
status: stable
description: >
  Detects rclone execution with command-line arguments indicating active cloud
  storage sync operations. rclone is consistently observed as an exfiltration
  utility in ransomware and data extortion incidents. Legitimate enterprise use
  is rare; any execution with remote sync arguments warrants investigation.  
references:
  - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
  - https://attack.mitre.org/techniques/T1567/002/
author: Cyber Mixology
date: 2026-05-09
tags:
  - attack.exfiltration
  - attack.t1567.002
  - social-engineering-intrusion-suite
logsource:
  category: process_creation
  product: windows
detection:
  selection_binary:
    Image|endswith:
      - '\rclone.exe'
  selection_args:
    CommandLine|contains:
      - ' copy '
      - ' sync '
      - ' move '
      - ' mega:'
      - ' s3:'
      - ' dropbox:'
      - ' gdrive:'
      - ' onedrive:'
      - ' sftp:'
      - '--config'
  condition: selection_binary and selection_args
falsepositives:
  - Authorized cloud backup or migration tools using rclone with IT approval
  - DevOps pipeline activity on CI/CD systems
level: high

Tuning tip: rclone on a workstation is almost always a red flag. rclone on a build server may be legitimate. Scope suppression to known CI/CD hostnames rather than suppressing broadly.

Rule 6: LSASS Memory Access by Non-System Process

Technique: T1003.001 — OS Credential Dumping: LSASS Memory

Mimikatz and its variants work by reading memory from lsass.exe — the Windows process responsible for managing credentials. Scattered Spider’s advisory specifically calls out Mimikatz usage. But the rule isn’t about Mimikatz. It’s about the behavior: a non-system process opening LSASS with memory-read permissions.

This is a well-understood detection with strong community backing. The rule below catches the core behavior regardless of what tool is doing the reading.

title: LSASS Memory Access by Non-System Process
id: 5d7f9b1c-3e5a-4c7e-9f1b-6a8c0e2f4b6d
status: stable
description: >
  Detects non-system processes requesting PROCESS_VM_READ or
  PROCESS_ALL_ACCESS on lsass.exe. This behavior is consistent with credential
  dumping tools including Mimikatz, SharpKatz, and custom LSASS dump utilities.
  Scattered Spider has used Mimikatz as part of their post-exploitation
  credential access phase.  
references:
  - https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a
  - https://attack.mitre.org/techniques/T1003/001/
author: Cyber Mixology
date: 2026-05-09
tags:
  - attack.credential_access
  - attack.t1003.001
  - social-engineering-intrusion-suite
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'    # PROCESS_VM_READ | PROCESS_QUERY_LIMITED_INFORMATION
      - '0x1410'
      - '0x143a'
      - '0x1438'
      - '0x1fffff'  # PROCESS_ALL_ACCESS
  filter_system:
    SourceImage|startswith:
      - 'C:\Windows\System32\'
      - 'C:\Windows\SysWOW64\'
    SourceImage|endswith:
      - '\MsMpEng.exe'
      - '\csrss.exe'
      - '\wininit.exe'
      - '\lsass.exe'
  condition: selection and not filter_system
falsepositives:
  - Legitimate EDR and AV products reading LSASS memory for protection purposes
  - Some backup and password manager tools
level: critical

Tuning tip: Expand the filter list with your EDR vendor’s process name. Most endpoint security products access LSASS legitimately. Identify them in your environment and exclude by image path, not just process name.

Thinking in Suites: The Bigger Lesson

Individual rules catch behaviors. Suites catch attackers.

Here’s what makes this collection more than the sum of its parts:

Tag consistently. Every rule above carries the tag social-engineering-intrusion-suite. In your SIEM, build a correlation rule that escalates when two or more rules from this tag fire on the same user or host within 24 hours. One alert is a signal. Two alerts are a pattern. Three is a case.

Tier your fidelity. Not every rule is created equal. The IdP federation rule (Rule 3) and LSASS access rule (Rule 6) are high-fidelity enough to alert individually. The RMM tool rule (Rule 4) needs context before it means much. Know which rules stand alone and which ones need corroboration.

Cover techniques, not tools. The RMM rule doesn’t care if it’s ngrok or Fleetdeck or something that didn’t exist six months ago. Maintain the binary list as a lookup table and update it regularly — but the detection logic stays the same. Scattered Spider will retire. The technique won’t.

Build for recall first, then tune for precision. Start with rules that cast a wide net. Measure your false positive rate. Then add conditions — parent process, execution path, time of day, IP novelty — to tighten precision without killing recall. A rule that never fires isn’t protecting you.

Wrapping Up

Scattered Spider made headlines because they were effective, not because they were uniquely sophisticated. The techniques they used — MFA fatigue, help desk impersonation, rogue IdP registration, RMM tool abuse — are available to any motivated attacker with patience and a phone.

The good news? Behaviors are detectable. Build a suite. Tag it consistently. Correlate across rules. And remember: you’re not hunting a name. You’re hunting a pattern.

The pattern is what matters.

Looking to go deeper? The MITRE ATT&CK framework and the Sigma HQ rules repository are excellent starting points for expanding any detection suite. The SigmaHQ repo includes community-maintained rules for many of the techniques covered here — always worth checking before writing from scratch.