Akira

Executive summary

Akira has been visible since 2023 as a ransomware and extortion operation with a mature attack chain. For Amuneth, the group is especially relevant because it hits exactly the weak spots that recur in many medium-sized and large organisations: VPN access, edge appliances, administrator accounts, virtualisation, backup servers and broad Windows file shares. An Akira claim should therefore not be read as only a malware alert. It is a signal that access, data theft and recoverability must be investigated together.

For executives, the most important lesson is that the incident does not start when files are encrypted. In Akira-like attacks, the preparation phase is often decisive. The actor or affiliate looks for access, makes the environment understandable, increases privileges, collects data and tries to weaken defensive or recovery options. When encryption becomes visible, the organisation is often already exposed at leadership level: data may have been stolen, confidence in backups may be damaged and decision-making is under time pressure.

The CISA/FBI/NCSC-NL advisory on Akira describes, among other things, Windows- and ESXi-focused payloads, impairment of security tools and a combination of TTPs and indicators. That makes Akira not only an endpoint threat, but a threat to server layers and virtualisation. A good dossier must therefore answer whether hypervisors, backup platforms, management consoles and privileged identity are separated well enough from normal user and domain routes.

Group and development

Akira is generally described as a financially motivated ransomware operation with RaaS-like characteristics. Public reporting places the group in the modern extortion model in which operators, affiliates and access brokers can reinforce each other. The name Akira therefore does not automatically say which exact exploit or tool was used. Per incident, the profile must reconstruct which access was really used and which phase can be supported with evidence.

The group drew attention through activity against varied sectors, including business services, education, technology, manufacturing, public services and healthcare-like environments. That breadth fits opportunistic ransomware: the actor does not only look for sectors, but especially for organisations where access, data volume and recovery dependency create enough pressure. For organisations, it is therefore mainly relevant whether a customer profile resembles earlier Akira targets: dependent on VPN, large shared data sets, weak segmentation, centrally managed backups or vulnerable virtualisation layers.

Akira must be managed as a living profile. New claims can point to other affiliates, different tooling or changed access patterns. Therefore every update in this PHP file should name source, date, confidence and incident phase. A short leak-site mention is useful as an OSINT signal, but not enough as a technical conclusion.

Methods and attack chain

The first investigation line is initial access. Collect VPN, firewall, RDP, proxy, SSO, identity and EDR logs. Check valid accounts, weak or missing MFA, password resets, new MFA methods, impossible travel, logins from unusual ASNs, old service accounts and remote access from unmanaged devices. With Akira it is essential not to filter valid login activity away as normal: a valid account can be the core of the incident.

After access come discovery and privilege build-up. Look for domain enumeration, share discovery, changes in admin groups, new local administrators, remote service creation, PowerShell, WMI, PsExec-like behaviour, RDP hops and access to management platforms. Check Veeam, hypervisors, domain controllers, file servers and EDR management especially sharply. When an actor understands or influences recovery capacity, the crisis shifts from a technical incident to a continuity problem.

Data theft and staging must be investigated separately. Relevant traces are mass file reads, use of archiving tools, temporary staging directories, large compressed files, Rclone or cloud-sync configurations, abnormal outbound traffic and access to sensitive shares outside normal working hours. The absence of encryption does not mean there is no incident. In double extortion, the data breach can be the dominant damage factor.

The encryption phase must be connected to earlier phases. Investigate ransom notes, changed extensions, stopped services, deleted shadow copies, EDR tampering, batch scripts, scheduled tasks and activity on ESXi or server layers. Build a timeline from the first suspicious login to the last known actor activity. That timeline must show which controls failed: identity, patching, segmentation, EDR, logging, exfiltration control or backup protection.

Attack pattern from public cases

In the CISA/FBI/EC3/NCSC-NL advisory, Akira is described as a group that has affected organisations in North America, Europe and Australia since March 2023. The group started with Windows-focused attacks and later expanded to Linux/ESXi variants. That is important: Akira is not only looking for workstations, but for systems that can affect many servers at once.

The known Akira chain often starts with remote access or valid accounts. Discovery then follows with tools such as Advanced IP Scanner, domain reconnaissance with nltest and net commands, credential access via LSASS dumps or browser databases, data movement through Rclone or WinSCP, and then encryption. The defensive lesson is concrete: detect network reconnaissance, credential dumping and data staging before the locker is launched.

Akira uses or abuses legitimate tooling. AnyDesk can provide remote access, Ngrok can create a tunnel to systems behind firewalls, Rclone can move data to external storage and WinSCP can transfer data. These tools are not automatically malicious, but combined with new admin rights, nighttime activity and large data volumes they are strong warning signals.

Akira history also shows changes in extensions and payloads. Early variants used, among others, the .akira extension; Megazord variants are linked in CISA context to .powerranges. For defence this means file extensions are useful for confirmation, but too late as primary detection. The organisation must see the preparation phase: VPN, discovery, credentials, staging and exfiltration.

Known IOCs and artefacts

CISA AA24-109A mentions, among others, w.exe with SHA-256 d2fd0654710c27dcf37b6c1437880020824e161dd0bf28e3a133ed777242a0ca as an Akira ransomware artefact. This is a hard file indicator from the advisory and is mainly useful for retro-hunting and scoping.

The same advisory mentions Win.exe with SHA-256 dcfa2800754e5722acf94987bb03e814edcb9acebda37df6da1987bf48e5b05e as an Akira encryptor. A hit on this file must be connected immediately to process tree, host, user context and timeline.

CISA mentions AnyDesk.exe with SHA-256 bc747e3bf7b6e02c09f3d18bdd0e64eef62b940b2f16c9c72e647eec85cf0138 and Gcapi.dll with SHA-256 73170761d6776c0debacfbbc61b6988cb8270a20174bf5c049768a264bb8ffaf. This points to remote-access artefacts that are relevant in Akira investigations.

For exfiltration, CISA mentions Rclone.exe with SHA-256 aaa647327ba5b855bedea8e889b3fafdc05a6ca75d1cfd98869432006d6fecc9 and Winscp.rnd with SHA-256 7d6959bb7a9482e1caa83b16ee01103d982d47c70c72fdd03708e2b7f4c552c4. With such hits, always check configuration files, destinations, command lines and data volume.

CISA also mentions ipscan-3.9.1-setup.exe with SHA-256 892405573aa34dfc49b37e4c35b655543e88ec1c5e8ffb27ab8d1bbf90fc6ae0 as a network scanner and winrar-x64-623.exe with MD5 7a647af3c112ad805296a22b2a276e7c as an archiving tool. Combined with file-share reconnaissance, these are concrete signals for discovery and data staging.

Victims and historical context

Public victim claims show Akira at varied organisations. In this profile, victim mentions should be used to recognise patterns, not to repeat names. Relevant questions are: which sector, which country, which dependency on remote access, which data types, which backup dependency and which publication pressure? This context helps determine whether a new claim is directly relevant to Amuneth customers.

Record per victim in the database: name, sector, country, claim date, source URL, named data types, indication of encryption, indication of data theft, publication status and relationship to supplier chains. The PHP profile describes the group; the database stores the history. Together they give researchers a useful view.

Detection and follow-up

Prioritise MFA on all remote access, patching of edge systems, restriction of service accounts, PAM or at least separated admin accounts, logging of identity events, EDR hardening, network segmentation, restriction of lateral administration routes and recovery tests in which domain compromise is simulated. Check explicitly whether backups are immutable or offline enough to recover outside the compromised domain.

An Akira hit in the feed should trigger fixed triage: validate the source claim, determine victim relationship, match sector and country, check technical exposure, run hunts on access and data movement, and inform management about uncertainties. The goal is not panic around the name Akira, but fast answering of the question whether the same attack chain is realistic in the own organisation.

Deep forensic dossier

An Akira investigation must pay special attention to the separation between office IT, server administration and recovery platforms. In many organisations, backup servers are technically reachable from the same domain in which users and administrators work every day. For an actor who already has valid credentials, that is attractive: the backup environment provides information about critical systems, retention, restore points and often service accounts with broad rights. The report must therefore state whether Veeam, hypervisors, storage management and domain controllers were reachable from the same administration route.

For remote access, analysis must go beyond whether MFA was enabled. Check which MFA method was used, whether push fatigue was possible, whether new methods could be registered, whether legacy protocols existed and whether service accounts had exceptions. If an Akira-like attack starts through VPN or edge, the weakness is often a combination of technology and process: old accounts, insufficient device binding, weak conditional access, missing monitoring and too much trust in a single login result.

The ESXi and virtualisation component makes Akira relevant for continuity analysis. An encryptor at hypervisor level can affect many virtual servers at once. Therefore investigate not only Windows endpoint logs, but also administration actions on clusters, snapshots, datastores, management interfaces and accounts that manage vCenter or comparable consoles. If that logging is not available, the report must state that explicitly, because missing visibility into virtualisation is a structural blind spot.

For data theft, the investigator must distinguish between data discovery, staging and exfiltration. An actor who searches shares or creates archives has not automatically moved data outside the organisation. At the same time, staging is already serious, because it shows which data was considered interesting enough. The profile must therefore place searches, file access, compression, outbound traffic and cloud tooling next to each other instead of looking only at known exfiltration IOCs.

A good Akira investigation also contains recovery observations. Which systems had to return first, which dependencies blocked recovery, which credentials had to be rotated, which backups proved usable and which systems could no longer be trusted? This information belongs in the actor profile because Akira is not only a threat to confidentiality, but to recovery command. An organisation that restores technically without sanitising identity and the administration layer risks renewed access.

For SOC teams, Akira hunts are most useful when translated into concrete queries per source. Identity: new MFA, impossible travel, login from unknown ASN, privilege change after login. Endpoint: credential access, PowerShell, WMI, tool staging, EDR tampering. Network: large SMB reads, outbound volume, traffic to cloud storage. Backup: unexpected console login, job change, repository access. Hypervisor: VM stop, datastore access and administration login. This distribution makes the profile operational.

What to watch for

With Akira, pay particular attention to signals around remote access, backup systems and virtualisation. Suspicious VPN sessions, new MFA methods, unusual admin logins, access to Veeam or hypervisors and sudden large file reads are more important than the name of the ransomware binary. An organisation that wants to resist Akira must be able to see who logs in, from which device, with which rights and which data is accessed afterwards.

Warning signals include: login from unknown countries or ASNs, use of old or dormant accounts, new local administrators, PowerShell or WMI activity on servers, access to backup repositories, unknown archives on file shares, Rclone-like traffic, EDR alerts about stopped services and administration actions on ESXi or vCenter outside normal change windows.

Akira becomes especially dangerous when the actor can grow from ordinary access into recovery resources. If backup servers, hypervisors and domain controllers are reachable with the same accounts or from the same network zones, the attack becomes a continuity crisis. The main question for visitors is therefore: can a compromised account also reach your recovery environment?

How to defend against Akira

Start with remote access. Enforce phishing-resistant MFA where possible, remove old VPN accounts, restrict service accounts, monitor new MFA registrations and block login from unusual locations. Combine this with tight patching of edge appliances and firewall rules that do not make management interfaces more broadly reachable than necessary.

Protect recovery capacity as if it were a crown jewel. Use separated administration accounts for backups and virtualisation, restrict access to Veeam, ESXi, Hyper-V and storage management, centralise logs and test recovery when the primary domain cannot be trusted. Immutable or offline backups are valuable only when recovery has actually been practised.

Focus detection on behaviour: privilege changes, lateral movement, mass file access, compression, data staging, cloud uploads, EDR tampering and hypervisor actions. A good Akira defence sees the attack before encryption becomes visible. If detection triggers only on encrypted files, it is too late for data theft and recovery command.

Victim pattern and lessons

Public Akira claims affect varied sectors, including services, education, technology, manufacturing and public organisations. The shared lesson is not one specific sector, but dependency on remote access, large shared data sets and recovery environments that are insufficiently separated from the normal domain.

For organisations with many virtual servers, the most important lesson is that ransomware at server or hypervisor level can affect a large part of the environment at once. A simple endpoint approach is then insufficient. Visitors must check whether hypervisor administration, backups and privileged identity are separately protected and monitored.

When an Akira claim appears in your sector, do not use it as a reason for panic but as a checklist: are VPN and MFA sound, are backups separated, are file shares monitored, is data staging visible and has recovery been tested? Those are the points on which an organisation can actually defend itself.

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 #StopRansomware: Akira Ransomware
• Ransomware.live — Akira

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.