Storm-1175 · StormEncryptor Ransomware

Storm-1175 — a financially motivated ransomware actor previously known exclusively for deploying Medusa — began deploying a new, previously undocumented, custom C++-based ransomware strain called StormEncryptor on August 2, 2026. This is the group's first observed operation since April 2026, and marks a departure from its established Medusa affiliate tooling.

The likely initial-access vector is CVE-2026-18577, an authentication-bypass vulnerability in N-able N-central that was publicly disclosed the same day StormEncryptor activity began and added to the CISA Known Exploited Vulnerabilities (KEV) catalog on August 3, 2026. Microsoft has not formally confirmed the initial-access vector for the StormEncryptor campaign, but the timing overlap is the basis for the attribution in current reporting. CVE-2026-18577 exploitation itself is out of scope for this pack — it is covered by the companion N-able-N-central-CVE-2026-18577-Hunt.html pack. This pack's detection focus is everything downstream of initial access: the post-exploitation attack chain and the StormEncryptor payload itself.

Per Microsoft Threat Intelligence reporting (relayed via secondary sources; see Section 2), Storm-1175's attack chain runs: exploit CVE-2026-18577 for initial access → abuse legitimate RMM tools (AnyDesk, SimpleHelp) for remote access and persistence → Advanced IP Scanner for internal recon → Mimikatz for LSASS credential dumping → lateral movement → pre-encryption data exfiltration → StormEncryptor deployment. Microsoft assesses the group can move from compromise to ransomware deployment within only a few days. StormEncryptor appends a .encrypted extension to affected files, drops a ransom note named !!!README_FIRST!!!.txt in every scanned directory, and threatens to publish stolen data if the victim does not make contact within three days.

Storm-1175's established operating pattern (documented against its prior Medusa operations, see Section 2 Microsoft Security Blog source) additionally includes: new local-admin account creation for persistence, WDigest registry manipulation to force plaintext credential caching, Microsoft Defender registry/PowerShell tampering to blind AV ahead of payload deployment, PDQ Deployer / Group Policy for ransomware push, and Rclone for pre-encryption exfiltration. These behaviors are not yet confirmed specifically for the StormEncryptor campaign, but given the group's documented tooling consistency they are included here as high-value hunt hypotheses.

Nine sources were fetched and saved verbatim to Storm1175-StormEncryptor-Hunt-sources/ during research. No standalone Microsoft Security Blog post specifically covering the August 2026 StormEncryptor campaign could be located as of this pack's research date (2026-08-10) — the April 6, 2026 Microsoft post covers Storm-1175's established Medusa-era TTP baseline, not StormEncryptor by name. All StormEncryptor-specific facts (hash, ransom-note filename, campaign date) are carried via secondary reporting (gbhackers, cyberpress) that explicitly attributes its findings to Microsoft Threat Intelligence. This gap is called out rather than papered over — treat StormEncryptor-specific claims as medium-high confidence (multi-source corroborated, MSTI-attributed) rather than primary-source-verified.

Decision: because CVE-2026-18577 exploitation is already covered by an existing pack, sources 5–8 above (CISA KEV, The Hacker News, Rapid7, N-able) are cited for attack-chain context and provenance completeness only — their IOCs (malicious IPs, svchost.exe/Cloudflared initial-access artifacts) are intentionally not duplicated into this pack's IOC appendix. This pack's CQL and IOC focus is the StormEncryptor payload and the post-access chain (RMM abuse → recon → credential theft → defense evasion → impact).

Hunt Hypotheses

• H1 (high): A host will show an abnormal volume of file-touch events consistent with an active StormEncryptor encryption sweep.
• H2 (high): The StormEncryptor ransom note (!!!README_FIRST!!!.txt) or .encrypted file extension will appear in file-write telemetry.
• H3 (high): The published StormEncryptor SHA-256 hash will appear in process-execution telemetry.
• H4 (medium-high): AnyDesk or SimpleHelp will be installed or executed outside the organization's approved RMM baseline.
• H5 (medium): Advanced IP Scanner will execute for internal host enumeration shortly after RMM access is established.
• H6 (high): Mimikatz or LOLBin LSASS-dump command lines will appear on a compromised host.
• H7 (high): The WDigest UseLogonCredential registry value will be set to force plaintext credential caching.
• H8 (high): PowerShell will be used to add Microsoft Defender exclusions or disable real-time protection immediately before payload deployment.
• H9 (high): Volume Shadow Copies or the Windows backup catalog will be deleted shortly before mass encryption begins.
• H10 (medium): A new local administrator account will be created for persistence.

Attack Chain

CVE-2026-18577's own exploitation IOCs (malicious source IPs, svchost.exe in the Documents folder, the Cloudflared service name) are published by N-able/Rapid7/CISA but are deliberately not duplicated here — they belong to the companion N-able-N-central-CVE-2026-18577-Hunt.html pack, which already covers that exploitation path.

Non-CQL checks that complement the Falcon queries in Section 8, using Windows Event Log, Sysmon, or vendor-side logging.

• Windows Security 4720 / 4732: local account created, then added to the Administrators group — corroborates Q10.
• Windows Security 7045 (System log): new service installation — check for a service named Cloudflared or unfamiliar tunnel/RMM services registered outside change windows.
• Sysmon Event ID 1 with Event ID 11 correlation: a binary renamed to mimic conhost.exe or another trusted process name — Storm-1175's established Cloudflare-tunnel masquerading pattern.
• Windows Defender operational log (Event ID 5001 / 1116): real-time protection disabled or a threat detected-but-not-remediated — corroborates Q8.
• File-share / NAS audit logging: a burst of file renames to *.encrypted or mass file writes from a single service account across multiple shares in a short window — corroborates Q1/Q2 for storage not covered by an endpoint sensor.
• N-central Take Control session audit (vendor-side, cross-reference only): sessions authenticated as the default MSP Support account from unexpected source IPs — feeds the companion CVE pack, but a hit here should raise this pack's priority for the same tenant.

Playbook 1 — Enable Credential Guard + LSA Protection (Windows, GPO)

Prerequisites: Windows 10/11 Enterprise or Server 2016+, UEFI with Secure Boot, virtualization extensions (VBS) enabled in firmware. Test on a pilot ring before fleet-wide rollout — some legacy credential-provider or third-party security software can conflict with VBS.
Reboot required: Yes — two reboots (one to enable VBS, one after Credential Guard activates).
Rollback: Set LsaCfgFlags back to 0 and disable the Device Guard/Credential Guard GPO, then reboot twice. Re-enabling WDigest caching is NOT part of the rollback — leave it disabled.

1. Computer Configuration > Administrative Templates > System > Device Guard >
   "Turn On Virtualization Based Security" = Enabled
   Credential Guard Configuration = "Enabled with UEFI lock"

2. Registry equivalent (for non-domain or scripted deployment):
   reg add "HKLM\SYSTEM\CurrentControlSet\Control\LSA" /v LsaCfgFlags /t REG_DWORD /d 1 /f
   reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f

3. Force disable WDigest plaintext caching (blocks the Q7 technique outright):
   reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential /t REG_DWORD /d 0 /f

4. Reboot, then verify:
   msinfo32  ->  "Device Guard Security Services Running" should list
   "Credential Guard"

Playbook 2 — AppLocker Rule to Restrict Unauthorized RMM Tool Execution

Prerequisites: AppLocker enabled and in at least Audit mode on target host groups; a documented, signed install path for your organization's approved help-desk RMM tool (if any).
Reboot required: No — the Application Identity service must be running, but policy application does not require a reboot.
Rollback: Remove or disable the deny rule in the AppLocker GPO and run gpupdate /force; no persistent system state is changed by this rule.

1. Deploy in Audit-only mode first for 2 weeks and review the AppLocker event log
   (Microsoft-Windows-AppLocker/EXE and DLL) for unexpected blocks.

2. Example deny-by-path rule (adjust to your approved RMM's actual signed path):
   New-AppLockerPolicy -RuleType Publisher, Path -User Everyone `
     -DenyRule -RuleNamePrefix "Deny-Unauthorized-RMM" `
     -FileInformation (Get-AppLockerFileInformation -Path `
       "C:\Users\*\Downloads\AnyDesk.exe","C:\Users\*\Downloads\SimpleHelp*.exe",
       "C:\Users\*\AppData\Local\Temp\*AnyDesk*.exe")

3. After the audit period, switch to Enforce mode:
   Set-AppLockerPolicy -PolicyObject $policy -Merge

4. Verify: attempt to launch AnyDesk from an unapproved path on a test host;
   confirm it is blocked and an AppLocker 8004 event is logged.

Validation gates from Section 11 apply to every query above marked "Good" or "Partial" before Custom IOA promotion. The two flagged gaps (lateral movement, exfiltration) reflect the fact that Storm-1175's specific tooling for these steps has not yet been confirmed for the StormEncryptor campaign — the queries in Section 7 (native hunts) provide interim coverage until vendor reporting confirms specific tool indicators.