AvosLocker

Executive summary

AvosLocker is a ransomware-as-a-service operation for which FBI and CISA published an updated advisory in October 2023. The advisory describes compromises in multiple US critical infrastructure sectors and impact on Windows, Linux and VMware ESXi environments. For visitors this is directly relevant: AvosLocker is not a pure Windows endpoint problem.

According to the advisory, the group uses legitimate software and open-source remote system administration tools, followed by exfiltration-based data extortion. That places AvosLocker in the modern ransomware chains where management tooling and data theft are central.

The main practical lesson is that remote access, PowerShell, RDP, ESXi and data exfiltration must be monitored together. When an actor can move through legitimate tooling, the attack becomes visible only when the organisation understands what normal administration looks like.

Group and development

AvosLocker operates as a RaaS model. Affiliates can use different access routes and tools, but the advisory names consistent defensive points: secure remote access, restrict RDP, harden PowerShell and patch software.

The platform reach matters. Windows, Linux and VMware ESXi require different logs, management processes and recovery procedures. An organisation with mature Windows EDR can still be blind on hypervisors or Linux servers.

AvosLocker uses exfiltration-based data extortion. Encryption is therefore not the only damage. Data stolen before encryption can later be used on leak sites or in negotiations.

Attack pattern from public cases

FBI/CISA describe AvosLocker affiliates using legitimate software and open-source remote administration tools. Detection depends on context: known tools become suspicious when used outside approved administration paths, by unusual accounts or against many systems at once.

The advisory names Windows, Linux and VMware ESXi. Incident response must therefore quickly determine which platforms were affected or reachable. ESXi impact is especially critical because many virtual servers can be affected at once.

RDP and PowerShell are explicitly named in mitigation actions. For defence they are core sources: RDP login patterns, PowerShell command lines, script execution, remote sessions and administrative actions.

Known IOCs and artefacts

Legitimate remote administration tools are an important artefact category. Record tool name, installation time, account, source host, target hosts and external connections.

Exfiltration-based extortion points to staging, compression, cloud transfer and outbound volume. These signals should be visible before encryption.

ESXi-related activity such as unexpected management logins, VM stop actions, datastore access and changes to snapshots or backup integrations are critical artefacts.

Practical detection logic

Create baselines for remote administration tools. Which tools are allowed, from which management servers, by which accounts and to which systems? Anything outside that matrix must be investigated.

Detect PowerShell risk: encoded commands, download cradles, execution from temporary paths, scripts that modify security services and PowerShell after suspicious remote login.

Monitor ESXi separately. Many organisations have good Windows logging but limited hypervisor logging. AvosLocker turns that into a direct blind spot.

Concrete hardening priorities

Secure remote access with phishing-resistant MFA where possible, allowlisting, logging and restrictions on supplier routes.

Restrict RDP and PowerShell. RDP should go through jump hosts and PowerShell should be logged, restricted and monitored.

Protect VMware ESXi with separate administration accounts, network restrictions, MFA where available, logging and tested restore procedures.

Patch software and firmware regularly, especially internet-facing systems and management platforms. AvosLocker defence starts by shrinking the attack surface.

Identity, naming and attribution

For AvosLocker, the operational starting point is an exact identity match. The local dossier records the following names or aliases: AvosLocker ransomware, Avos. 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 AvosLocker is 2021-06-13; 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 AvosLocker 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 alert: FBI and CISA Release Update on AvosLocker Advisory
• CISA/FBI AA23-284A AvosLocker Ransomware Update PDF
• 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 — AvosLocker

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.