G0119: Indrik Spider
MITRE ATT&CK G0119: Indrik Spider Group details, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
Indrik Spider matters because the ATT&CK record ties the group to a progression from banking malware to targeted ransomware operations and a diversified toolset after sanctions and indictment. For leaders, the practical issue is not the group name alone; it is whether the organization can detect and contain the behaviors commonly associated with financially motivated intrusion operations: credential theft, valid-account abuse, remote execution, lateral movement, tool transfer, staging, and ransomware-enabling activity.
Executive priority
Prioritize this as an operational resilience and incident-readiness problem. The supplied relationships point to Windows-heavy credential and lateral-movement tradecraft, plus cross-platform post-exploitation tooling. Executives should ask whether identity controls, privileged access monitoring, endpoint visibility, remote access governance, and ransomware response playbooks are validated with evidence—not assumed. The sanctions-related references also make legal, compliance, and payment decision workflows relevant during ransomware response, but local counsel and incident-specific facts are required.
Technical view
ATT&CK does not provide an official detection section for this group, so coverage should be validated from the related software and techniques. Focus on credential access to LSASS, use of Mimikatz, valid domain account abuse, RDP and SSH lateral movement, PsExec and WMI execution, PowerShell/cmd/JavaScript execution, registry query or modification, remote system and service discovery, ingress tool transfer, local data staging, and use of post-exploitation frameworks such as Cobalt Strike, Empire, and Donut-generated payloads. Treat legitimate admin tools like PsExec, WMI, RDP, SSH, and PowerShell as high-context detections: the value comes from correlating identity, host, process, network, and administrative-change telemetry.
Likely telemetry
- Endpoint process creation and command-line logging for PowerShell, cmd, WMI, PsExec-style execution, registry utilities, and scripting engines
- Windows security events and authentication logs for domain account use, privileged logons, RDP sessions, and unusual lateral movement
- EDR memory-access telemetry and alerts related to LSASS access or credential dumping behavior
- Registry query and modification events on Windows hosts
- Network telemetry for remote service use, tool transfer, command-and-control-like connections, and internal discovery patterns
Detection direction
- Validate detections across behavior chains, not just malware names: credential access followed by valid-account use, remote execution, discovery, tool transfer, staging, and ransomware precursor activity should raise priority.
- Tune detections for legitimate administration tools. PsExec, WMI, PowerShell, RDP, SSH, and registry utilities are common in normal operations, so baselines for administrators, servers, maintenance windows, and approved tooling are essential.
- Confirm visibility into LSASS access and credential dumping attempts, including whether endpoint controls generate usable evidence before credentials are reused.
- Correlate identity events with endpoint and network telemetry to identify domain account abuse and lateral movement that may not look malicious in a single log source.
- Hunt for post-exploitation framework indicators and behaviors associated with Cobalt Strike, Empire, and in-memory payload loading, while avoiding reliance on static indicators alone.
Mitigation priorities
- Start with identity hardening: reduce standing privilege, protect domain accounts, enforce strong authentication for remote access, and monitor privileged account use.
- Harden credential theft paths by limiting local administrator exposure, protecting LSASS where feasible, and reviewing credential caching and administrative workstation practices.
- Constrain lateral movement by limiting RDP, SSH, WMI, and PsExec-style access to approved administrative sources and documented use cases.
- Improve endpoint and server logging before an incident: process command lines, script logging, registry activity, authentication events, and file staging evidence should be retained long enough for investigation.
- Prepare ransomware response decisions in advance, including isolation authority, backup validation, legal/compliance escalation, and sanctions-aware payment governance.
Additional notes and limits
The group aliases supplied include Indrik Spider, Evil Corp, Manatee Tempest, DEV-0243, and UNC2165. The official description states the group is Russia-based, active since at least 2014, associated with Dridex and later ransomware operations including BitPaymer, WastedLocker, and Hades, and that it changed tactics and diversified tooling after U.S. sanctions and a 2019 indictment. Relationship context supplies the main basis for defensive prioritization.
The group object has no official ATT&CK detection text, no group-level platforms or tactics specified, and the relationship descriptions are partial summaries. This take does not establish current activity, customer exposure, or guaranteed detection. Local telemetry, asset scope, identity architecture, and incident evidence are required to determine risk and coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Indrik Spider
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.