G1046: Storm-1811
MITRE ATT&CK G1046: Storm-1811 Group details, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
Storm-1811 matters because ATT&CK describes it as a financially motivated group linked to Black Basta ransomware deployment and notable for social engineering that can look like normal help desk activity: inbox flooding followed by a fake support interaction and use of remote assistance tooling. For leaders, the key issue is not just phishing prevention; it is whether employees, service desks, identity teams, and the SOC can recognize and contain a support-themed intrusion before it becomes remote control, lateral movement, data staging/exfiltration, or ransomware deployment.
Executive priority
Prioritize validation of help desk procedures, remote support tool governance, privileged access monitoring, and ransomware response readiness. This behavior can pressure business continuity because the supplied ATT&CK relationships include Black Basta ransomware, Quick Assist, remote desktop software, SMB/SSH lateral movement, data staging, exfiltration, and common administrative tools such as PsExec, BITSAdmin, Impacket, PowerShell, and Windows command shell. Executives should ask: who is allowed to initiate remote assistance, how users verify support requests, whether remote admin tools are inventoried and logged, and whether IR playbooks connect social engineering reports to endpoint, identity, and network containment actions.
Technical view
ATT&CK provides no official detection text for Storm-1811, so defenders should build coverage from the documented relationships. Validate detections for unusual remote assistance sessions, especially Quick Assist or other remote desktop software following user-reported email flooding or help desk contact. On Windows, review telemetry for PowerShell, cmd, PsExec, BITSAdmin, SMB admin share activity, domain account discovery, user discovery, local data staging, encoded/encrypted files, deobfuscation, masquerading, and tool transfer. Where ESXi, Linux, or macOS are in scope, validate SSH activity, remote access, staging, and exfiltration monitoring aligned to the related techniques. IR teams should treat confirmed unauthorized remote support sessions as potential hands-on-keyboard access and rapidly scope identity use, lateral movement, staged data, and ransomware precursors.
Likely telemetry
- User reports and mail telemetry showing abnormal inbox flooding or high-volume non-malicious spam preceding help desk contact
- Help desk tickets, chat/phone records, and user verification logs related to remote assistance requests
- Endpoint process creation for PowerShell, cmd, PsExec, BITSAdmin, remote support tools, and renamed or oddly located executables
- Quick Assist and other remote desktop software execution, installation, session, or network connection logs where available
- Windows authentication, SMB/admin share access, service creation, and lateral movement evidence
Detection direction
- Correlate social signals with technical events: email bombing plus remote assistance use plus new process execution is more meaningful than any single event alone.
- Baseline legitimate Quick Assist and remote desktop software use; alert on unexpected initiators, unusual timing, first-time use, or sessions involving privileged users or sensitive systems.
- Tune administrative-tool detections carefully because PsExec, BITSAdmin, PowerShell, cmd, Impacket-like behavior, SMB, and SSH can be legitimate; prioritize context such as source host, account privilege, destination criticality, and sequence of activity.
- Look for post-access chains: remote support session followed by discovery, tool transfer, masquerading, encoded files, data staging, exfiltration, or lateral movement.
- Validate visibility gaps around help desk workflows, unmanaged remote support tools, ESXi hosts, SSH-enabled systems, and encrypted outbound traffic that is not part of approved business operations.
Mitigation priorities
- Harden support workflows first: require strong user verification, prohibit unsolicited remote assistance, and train users to report inbox flooding and unexpected help desk contact.
- Govern remote assistance and remote desktop software: define approved tools, restrict who may initiate sessions, and log usage centrally where feasible.
- Strengthen identity controls for privileged and support accounts, including least privilege and review of accounts that mimic legitimate names or resources.
- Improve endpoint and server monitoring for administrative utilities, scripting shells, tool transfer, masquerading, staging, and lateral movement over SMB or SSH.
- Prepare ransomware response around the Black Basta relationship: confirm backup resilience, segmentation, critical asset isolation, and containment procedures for Windows and ESXi assets where present.
Additional notes and limits
The supplied ATT&CK object identifies Storm-1811 as financially motivated and linked to Black Basta ransomware deployment, with social engineering involving email inbox flooding and fake help desk interaction. The strongest defensive value comes from connecting human-process telemetry with endpoint, identity, remote access, and network evidence. Relationship context materially expands what teams should validate, especially Quick Assist, remote desktop software, administrative utilities, lateral movement, discovery, staging, exfiltration, and ransomware-related readiness.
Platforms and tactics are not specified on the Storm-1811 group object, and official detection content is not provided. Platform references in this take come only from related software and technique objects, not from a group-level platform declaration. Local validation is required to determine whether Quick Assist, remote desktop software, SMB, SSH, ESXi, Linux, macOS, or specific administrative tools are present and monitored in the reader’s environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Storm-1811
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.