An attacker logged into the RDP Honeypot and quickly ran Ako Ransomware. The attacker had opened the Defender GUI to disable it–but a bot from the previous day had already disabled it. The attacker then dropped Locker.exe, ran it, and then logged off before the execution had completed. Locker.exe is also known as Ako and MedusaLocker Reborn. See info on Ako Ransomware, the timeline of the attack, the summary and IOCs below.
Ako Version 1.0
Ako was delivered via Locker.exe, which is a self contained PE that when run, it encrypts everything except for .exe,. dll, .sys, .ini, .lnk, .key, .rdp extensions, and a few blacklisted folders. Ako appends the same randomly generated key to each file it encrypts, which is specific to that ransomware incident.
Before Ako encrypts files it performs four tasks, it disables recovery, deletes shadow files, deletes backups and adds 2 registry keys. Ako runs the following commands:
vssadmin.exe Delete Shadows /All /Quiet
bcdedit.exe /set {default} recoveryenabled No
bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
wbadmin DELETE SYSTEMSTATEBACKUP
wbadmin DELETE SYSTEMSTATEBACKUP -deleteOldest
wmic.exe SHADOWCOPY /nointeractive
Ako also creates two registery keys:
Key: HKEY_CURRENT_USER\Software\acfg
Name: aid
Value: .(randomly generated key)
Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Name: EnableLinkedConnections
Value: 1
Ako creating the above key to ensure mapped drives will work at an elevated UAC prompt. (More info on that here). Ako will also scan for file shares and encrypt those too, if possible according to other reports.

Then, Ako droped a ako-readme file and a do_not_remove file with the key in the name.

Ransom note – ako-readme

After base64 decoding do_not_remove_ako

Shout Out to Kremez
Apparently, the creators of Ako are fond of Vitali Kremez (). We were poking through the strings and came upon this:

I was reviewing some recent tweets by Kremez, and he tweeted about Ako Ransomware just a few days ago. (Which can be seen ). According to him, it sounds like version 1 was recently released.
The Ransom
Here’s what you see when you go to their Tor site:

The price tag to unlock one machine, $3,500 USD. So, if you would like to donate to our Bitcoin wallet… 😉

Timeline
14:49 Attacker logs in and out from 185.167.160.83. Probably the scanner brute forcing the password
14:52 Attacker logs in from 185.167.160.83
14:53 Attacker copies Locker.exe over RDP

14:53-14:58 Attacker attempts to disable Defender but it was already disabled
14:59 Attacker runs Locker.exe
14:59 Attacker logs off
15:00 Registry keys added, ako files created (readme/do_not_remove), above commands ran
Summary
As far as I know, there is not a free decryption program for this ransomware yet. Even though most EDR/AV companies detect/block Ako, it’s easy enough for attackers to disable Defender or other security programs, if they are admin. When this happens, how do you detect bad?
Can you detect the commands that were ran by Ako? If not, build signatures or turn to something like Sigma. Here is a rule to detect the vssadmin command but this doesn’t cover the others. This rule is close, but could be expanded upon.
In this scenario we did not see any smb scanning, but it had been noted in previous incidents this year.
More information on Ako can be found at the following locations: BleepingComputer , BleepignComputer2 , and engimasoftware
IOCs
Attacker IP: 185.167.160.83
ae8e02d15c9b45a751e4e7f177f27f5ba7663fe6ec4b53cc68a6c1f5c2a3cfd9
Commands:
vssadmin.exe Delete Shadows /All /Quiet
bcdedit.exe /set {default} recoveryenabled No
bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
wbadmin DELETE SYSTEMSTATEBACKUP
wbadmin DELETE SYSTEMSTATEBACKUP -deleteOldest
wmic.exe SHADOWCOPY /nointeractive
Registry Keys:
Key: HKEY_CURRENT_USER\Software\acfg
Name: aid
Value: .(randomly generated key)
Key: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Name: EnableLinkedConnections
Value: 1
https://app.any.run/tasks/5f4740c6-023a-4214-a96a-97b05e8b440e/