AvosLocker (S1053)

What this ATT&CK software record represents

AvosLocker (S1053) is an Enterprise ATT&CK software record. ATT&CK uses Software as a broad category that can include custom malware, commercial or open-source tools, built-in operating-system utilities, and other code used to perform modeled behavior.

The official directory summarizes public reporting that describes ransomware offered through a ransomware-as-a-service model. The record is a research anchor, not a verdict that any appearance of the name or executable automatically proves malicious activity.

Defenders should evaluate execution context, provenance, identity, parent process, command line, network behavior, affected assets, and surrounding timeline before deciding whether use is authorized, suspicious, or malicious.

Names, variants, and identification confidence

Associated names recorded for this BMC launch profile are: No associated software names were copied into this launch profile; consult the official record for current naming relationships.

A family name can cover multiple versions, builders, forks, or vendor naming conventions. Conversely, the same filename or utility name may refer to legitimate software and unrelated malicious copies.

Record the exact artifact, version, hash, path, signer, configuration, and source report. Normalize to the ATT&CK identifier only after preserving those details.

• Distinguish family-level identification from a hash-level match.
• Verify code-signing and package provenance rather than trusting a filename.
• Treat behavioral similarity as a hypothesis when static identifiers are absent.
• Preserve uncertainty when vendors disagree on family boundaries or aliases.

Dual-use and context

Some ATT&CK software is explicitly malicious, while some is ordinary administrative or assessment tooling. Even malware may be studied safely in isolated research environments, and legitimate utilities may be abused in an intrusion.

For AvosLocker, determine whether the observed use was expected for the asset, identity, time, and business process. Context is often more durable than a simple allow-or-block rule.

• Was the binary or script installed through an approved process?
• Did an authorized identity execute it from an expected location?
• Do command-line arguments and network destinations match the documented purpose?
• Was the activity preceded by suspicious access, credential use, or process injection?
• Does the execution create persistence, collect sensitive data, or change security controls?

Use ATT&CK technique relationships carefully

Software-to-technique relationships in ATT&CK reflect publicly reported capabilities or observed use. They are not a promise that every version implements every behavior, and they do not prove that a technique occurred in your environment.

Convert each relevant relationship into a detection hypothesis with an expected event, data source, environment scope, benign comparison, and test method. Prefer behavior analytics that survive filename, hash, or packaging changes.

Detection engineering questions

A useful software profile connects artifact knowledge to telemetry and response. Combine high-confidence indicators with behavior, identity, and asset context instead of relying on one fragile signature.

• Can endpoint telemetry show process ancestry, command lines, module loads, and file writes?
• Can identity and cloud logs connect the execution to an authenticated user or workload?
• Can network telemetry distinguish expected administration from unusual external communication?
• Are detection rules resilient to renamed binaries, alternate paths, script wrappers, and updated hashes?
• Is isolation or containment safe for the business process hosted by the affected asset?

Investigation workflow

If AvosLocker is detected or reported, verify the artifact before expanding the incident. Collect metadata and execution evidence, identify the earliest appearance, map affected identities and systems, and determine what behavior actually occurred.

Then use the official ATT&CK page and its underlying references to identify collection opportunities. Do not assume every group associated with the software is a plausible attribution for the local event.

• Validate the detection and preserve the original artifact safely.
• Establish execution, persistence, credential, network, and data-access timelines.
• Separate observed behavior from capabilities described only in public reporting.
• Search for behaviorally related activity across the correct retention window.
• Document eradication, recovery, and lessons learned without overstating attribution.

Safe practitioner exercise

Review the official AvosLocker record and choose three listed techniques. In a lab or tabletop, design one analytic hypothesis for each technique using synthetic events or approved administrative activity—do not execute malware or reproduce harmful procedures.

For each hypothesis, state required telemetry, expected false positives, validation steps, and the response decision the analytic should support.

Version, attribution, and independence

This page was reviewed against Enterprise ATT&CK v19.2. Verify the official S1053 record for current software type, associated names, group relationships, techniques, and references.

© 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. Bare Metal Cyber is not affiliated with or endorsed by MITRE. The instructional analysis on this page is original Bare Metal Cyber content.

Certification relevance

This subject appears in or supports the following certification bodies of knowledge:

Authoritative sources

• MITRE ATT&CK® AvosLocker (S1053)
• MITRE ATT&CK® Software Directory
• MITRE ATT&CK® Data & Tools
• MITRE ATT&CK® Legal and Branding Guidance