Technical Curiosities of Akira Ransomware

Samples and Keys

We've observed samples of the primary (encryptor) component of Akira ransomware coming in two flavors: as a smaller (573 KiB) and as a bigger-sized (1.005 KiB) standalone executable. In both cases, the file is compiled with MSVC and has no obfuscation. From the victim's perspective, both types of samples produce the same result after execution: valuable files become encrypted and change their extension to .akira, and every directory where it happens receives a copy of akira_readme.txt containing ransom demands. The text of the readme file is consistent across executables, with the only varying part being the unique code it offers to log into the chat with the attackers. Here is a snippet from this file:

Hi friends,

Whatever who you are and what your title is if you're reading this it means the internal infrastructure of your company is fully or partially dead, all your backups - virtual, physical - everything that we managed to reach - are completely removed. Moreover, we have taken a great amount of your corporate data prior to encryption.

Well, for now let's keep all the tears and resentment to ourselves and try to build a constructive dialogue. We're fully aware of what damage we caused by locking your internal sources. At the moment, you have to know:

-- truncated --

Since Akira embeds the readme into the executable as plain text, the chat code represents the first binary difference between samples within each category. The second difference is a 4.096-bit key. Executables of the smaller size have the key in its base64-encoded form (i.e., using the recognizable -----BEGIN PUBLIC KEY------ header), while the bigger ones store it as a binary blob.

Figure 1 - An Akira sample with a plain-text key

Before the program starts encrypting files, it attempts to erase volume shadow copy snapshots. It does that by spawning a PowerShell process via WMI's Win32_Process.Create and then waiting for it with a 15-second timeout. The invoked command line is static and is, thus, highly suitable for detection purposes:

powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject"

After that, the executable initializes its multi-threading capabilities and starts traversing the disk from its root, encrypting files (with some exceptions) and leaving copies of akira_readme.txt behind.

Use of Restart Manager

One peculiar feature of this ransomware is how it approaches overwriting files currently opened by other programs. Akira abuses Restart Manager – a Windows API designed for installers and updaters that allows temporarily and politely shutting down applications that lock specific files. While Restart Manager doesn't grant extra access to the caller – who still needs to pass regular permission checks to terminate processes or stop services – it offers a useful primitive by telling which exact actions to take to unlock any given file.

Figure 2 - Restart Manager sessions in the registry

Akira is not the first ransomware family that relies on this functionality. As mentioned in this CrowdStrike blog post (see its second part) about Restart Manager internals, Conti already did that two years ago. While CrowdStrike did an excellent job describing the capabilities and limitations of the API, they haven't touched on the crucial subject of recovering forensic artifacts that programs leave behind while interacting with Restart Manager.

Akira follows a somewhat typical sequence of calls to the Restart Manager API:

RmStartSession -> RmRegisterResources -> RmGetList -> RmShutdown

The first function initiates a new Restart Manager session, the second attaches a list of files the program wants to unlock, the third enumerates applications and services that prevent accessing these files, and the fourth attempts to terminate them. While it's possible to specify multiple resources on the second step, Akira passes one file per session. Additionally, it uses the RmForceShutdown flag with RmShutdown to avoid waiting. Finally, one detail makes collecting artifacts much easier: the ransomware forgets to call RmEndSession. This mistake results in Restart Manager not deleting the session record from its database, allowing the artifacts to outlive the owning process. Speaking of which, Restart Manager stores information about its sessions in a per-user registry location: HKEY_CURRENT_USER\SOFTWARE\Microsoft\RestartManager

Despite being part of the registry, the key only exists in memory and does not persist in the corresponding hive file due to the REG_OPTION_VOLATILE flag. In other words, shutting down the system deletes the key and its content. For the same reason, forensic tools that capture registry hive files for later analysis do not allow exploring the Restart Manager database because it only exists in the live registry. Combining these facts with the difficulties in interpreting the data (Restart Manager stores some fields as REG_BINARY and others as REG_MULTI_SZ with strings mixed with hex-encoded identifiers), collecting these artifacts starts sounding like a job that requires automation. In our next blog post, we will share a tool that captures and exports Restart Manager database content into human- and machine-readable forms.

So, what information can we recover? In addition to the list of resources passed to RmRegisterResources (which can include files, services, and processes), each session key stores the PID and process creation timestamp of the session owner/creator. And since the storage medium for the database is the registry, the system also keeps track of the last modification time. When combined, these details can be valuable for reconstructing the incident timeline.

Detection-wise, Restart Manager API is quite noisy. We've observed the following Windows Event Log events on the default Windows configuration. Machines infected with Akira ransomware show an excessive number of these events compared to baseline behavior.

Unfortunately, these events provide little detail and context. Luckily, it's easy to augment them with Sysmon events 12-14. You can configure logging for the SOFTWARE\Microsoft\RestartManager path under any/specified user hives and audit the use of the API by tracking the corresponding changes to the Restart Manager database.

What looks like a typo

While observing the behavior of Akira samples from the bigger-sized (1 MiB) category, you can notice that, in addition to overwriting existing files, it also creates and later deletes some temporary files inside the encrypted directories:

Figure 3 - A ProcMon capture of .arika files being created

Despite being random-looking, these names (consisting of 16 bytes in hex) are identical across runs, indicating that their origin is far from random. And yes, for some reason, these files have a .arika extension (which might or might not be a typo in .akira). Anyway, given a known naming pattern, we can use the Sysmon FileDelete event (ID 23) to archive these files upon deletion for further inspection. Here is the minimal Sysmon config for it:

<Sysmon schemaversion="4.90">
  <ArchiveDirectory>SysmonArchive</ArchiveDirectory>
  <EventFiltering>
    <FileDelete onmatch="include">
      <TargetFilename condition="end with">.arika</TargetFilename>
    </FileDelete>
  </EventFiltering>
</Sysmon>

After recovering them from the Sysmon archive, we can see that all these files have the same size and structure. Each file starts with a 20-byte header followed by 512 bytes of high-entropy data that changes between runs. Here is an example:

Figure 4 - A recovered .arika file.

It's hard to tell what the purpose of these files is without reverse engineering how Akira derives and uses their content. Yet, given their sizes, entropy, and the temporary nature of the involved data, we might be looking at some intermediate key material. Confirming or dismissing this possibility, however, is up to subsequent research.

Detectability

Overall, security software should have no difficulty detecting Akira ransomware. The samples contain easily recognizable strings suitable for static detection; they rely on documented APIs that generate rich telemetry; they follow a predictable pattern of actions that should undoubtedly raise alerts. Akira tries to erase volume shadow copies, traverses the disk while overwriting and renaming files to a predefined extension, creates templated ransom notes, and abuses Restart Manager API. All these behaviors are possible and easy to cover with runtime detection.