Maze

Management summary

Maze is historically one of the most important ransomware groups because the operation made double extortion visible mainstream. Where older ransomware was mainly about encryption, Maze used stolen data as an additional leverage. For visitors, Maze is therefore not a current hampered threat-profile, but a core case for why data diode and leak sites are central to modern ransomware.

Many contemporary groups use a model that helped to normalize Maze: access, data collection, encryption systems and then threaten publication. The group itself is no longer dominant, but the model is everywhere.

The main lesson is that defense against ransomware is always defence against exfiltration. Backups recover files, but do not restore any leaked customer data, contracts or personal data.

Grouping and development

Maze became active around 2019 and received attention by publishing stolen data from victims who did not pay. This changed the balance of power in ransomware negotiations: even organisations with good backups could remain under pressure due to data breach risk.

The operation later stopped publicly, but the double-extortion model was taken over by other groups. Maze is therefore historically relevant and should not disappear from the profiles.

In an actor library, Maze should be used as a source profile for leak-site extortion and data-driven pressure.

Attack pattern from public cases

Maze-like attacks often began with access via phishing, operation or remote access, followed by exploration of internal data and lateral movement. The specific vector differed per incident but the goal was consistent: finding data that produces publication pressure.

The group used the publication of stolen data as a means of printing. For detection, this means that file access, staging, archiving and outbound traffic can be visible rather than encryption.

The impact phase combined encryption with reputation and reporting risk. That is exactly why modern ransomware should not be treated as a purely availability incident.

Known IOCs and artifacts

Maze -IOC . Use old hashes and notes for retro-hunting, but do not rely on these indicators for modern detection.

The most important artifacts are datastaging, leak-site publication, ransom notes and evidence files displayed to victims.

Behaviorally Maze is recognizable by the combination of data steal and encryption.

Practical detection logic

Detect unusual access to crown jewel data. Maze shows that sensitive data itself is the leverage.

Look for compression and stairs on file servers. Large archives just before encryption are a classic double-exercise indicator.

Link leak site claims to internal telemetry. A claim is OSINT, not technical evidence, but should lead directly to log research.

Concrete Hardening Priorities

Centralize identity and remote access. Most historical ransomware chains did not start with a magic payload, but with valid access, phishing, vulnerable external services or reused credentials. MFA, device binding, account hygiene and logging are the first defense layer.

Protect data before encryption starts. Monitor massive file access, compression, staging, cloud transfer, Rclone-like behavior and unusual outbound volumes. Double extortion makes data steal just as important as encryption.

Separate backup, hypervisor and management accounts of regular domain routes. Historical groups sometimes disappeared, but their lesson remains: repairability fails when the same compromised identity can manage production and recovery.

Make a data breach response plan part of ransomware preparation. Legal, contractual and communication steps should be ready before a leak site claim appears.

Limit wide data access. Least privilege on file shares is a direct ransomware check.

Identity, naming and attribution

For Maze, the operational starting point is an exact identity match. The local dossier records the following names or aliases: Maze ransomware. An alias is a search aid, not independent evidence of shared operators. Similar names, reused logos and the same extortion vocabulary cannot establish a relationship between groups. Analysts should retain the original spelling of a claim and distinguish the publisher, malware family and suspected intrusion operator. Those roles can belong to different people. This prevents an incident being assigned to the wrong group simply because a filename or public post resembles an earlier case. Any proposed relationship needs its own dated, attributable source.

Timeline and interpretation of dates

The source registry date available for Maze is 2019-10-21; the metadata snapshot was collected on 2026-09-15. These timestamps describe the available record, not a proven beginning of criminal operations. Registration may follow earlier activity, and a claim can concern an older incident. A defensible timeline separates suspected intrusion, data access, discovery by the victim, publication by the claimant and discovery by the monitoring service. The profile review date is another independent timestamp. Analysts should not silently convert one date into another. When sources disagree, preserve both observations and their provenance, then explain the uncertainty rather than presenting a falsely precise attack chronology.

Victim claims and targeting assessment

The victim panel for Maze shows up to five distinct organisations from the stored claim history. It is a moving observation window, not a complete incident census. Public listings can omit victims, repeat old material or exaggerate access. Consequently, a short run of organisations in one country or industry does not by itself prove deliberate targeting of that sector. The useful comparison is with the organisation's own dependencies: shared providers, remote access arrangements, exposed services and sensitive data flows. A supplier appearing in a claim justifies verification through established contacts, but does not establish that downstream customers were compromised. Separate confirmed statements from the claimant's assertions.

Indicators of compromise (IOCs)

Indicators are historical observations, not proof of a current infection. Validate source, age and context before hunting or blocking; legitimate administrative tools can produce false positives.

Sources

• CISA Ransomware Guide
• MITRE ATT&CK — Valid Accounts (defensive context)
• MITRE ATT&CK — External Remote Services (defensive context)
• MITRE ATT&CK — Exfiltration Over Web Service (defensive context)
• MITRE ATT&CK — Inhibit System Recovery (defensive context)
• Ransomware.live — Maze

Evidence and limitations

Attribution describes the source assessment, not a verified identity. A leak-site listing alone does not prove encryption, data theft, a particular vulnerability or an affiliate relationship. Missing information is left explicit.