Currently working as a Senior Consultant at Netcompany spending my full-time job solving the SharePoint riddles. In the free time I'm expanding my understanding of cybersecurity through hacking activities. Git fanboy.
Our clan's network has been infected by a cunning ransomware attack, encrypting irreplaceable data essential for our relentless rivalry with other factions. With no backups to fall back on, we find ourselves at the mercy of unseen adversaries, our fate uncertain. Your expertise is the beacon of hope we desperately need to unlock these encrypted files and reclaim our destiny in The Fray. Note: The valuable data is stored under \Documents\Work
Before opening the file I'm marking the files as readonly and noting down its hash. File system contained in AD1 image can be browsed with a FTK Imager.
Extension: *.ad1
AD1 (Access Data 1) is a disk image file used to hold file-level acquisitions. This format is exclusively used in the Forensic Toolkit by Accessdata.
From the challenge description we know that:
owner of the files was struck with a ransomware rendering the files unusable,
important files are located under \Documents\Work; because this is Windows system I assume it's %USERPROFILE%\Documents\Work
objective: recover file
Retrieving encrypted files
Content of the important directory
I'm inspecting the ULTIMATIM.hta file using the FTK Viewer preview panel. It looks like a ransomware note.
The only thing that is worth noting down is the Faction ID that could be used later.
In the meantime I do explore other files in the directory, but these are not relevant for us right now, so I am not elaborating on this one. I did also check hashes for other ransomware notes to make sure I did not falsly assume that all are the same - but they are the same.
Because the hex preview in the FTK Viewer really looked like some mangled bytes, I have no hopes that strings won't find anything of value, and I am not mistaken.
Right now I don't have tools to restore the file.
Malware hunting
Let's backtrack a bit. We are looking at the end of the process and we have to look for the evidences of previous steps that most certainly had occurence. So what are these steps? These vary from the source to source, but let's take the core ones:
Infection.
Execution - data exfiltration, data encryption
Spreading.
Persistence.
Clean up.
So at this point we are looking for any traces of
unknown files (in Downloads, Desktop, c:\temp, etc), that includes especially executable files (DLLs and EXEs)
suspicious connections (HTTP over port 80, nc uses)
any PowerShell executions (regular users rarely if ever use PowerShell; system rarely)
anything really that outstands
Reverse shell
This one is a suspicious file and should not be there - without doubt. Unfortunately, it is of no use in this scenario.
Using famous Eric Zimmerman's Windows 10 Timeline database parser allowed me to browse through the ActivitiesCache.db - nothing paticulary interesting (7z2107-x64.exe, ftk imager.exe, treesizefree.exe).
Windows Defender
Finally, I started analyzing the Windows Defender logs (C:\ProgramData\Microsoft\Windows Defender\Support\). Here are the findings:
(SAM dumping) C:\Windows\System32\cmd.exe(cmd.exe /c reg.exe save hklm\sam C:\Users\TOMMYX~1\AppData\Local\Temp\crkrbigyfjqk)
Security Account Manager
SAM (Security Account Manager) is a database file that stores users' passwords. The user passwords are stored in a hashed format in a registry hive either as an LM hash or as an NTLM hash. This file can be found in %SystemRoot%/system32/config/SAM and is mounted on HKLM/SAM and SYSTEM privileges are required to view it.
Almost all of them are self explainatory - apart from intel.exe. Could it be the actual crypter? Unfortunately all of the above executables can no longer be found at their destination. So can we somehow obtain the files? We don't have *.pcap file to grab the binary stream, we don't have access to any memory dumps for more binary dumping from RAM.
But there is another place we can look for this file.
Bingo.
Windows Defender Quarantine
We can't access the binaries becasue of how they are stored in the quarantine.
So for that I'm using a Python scriptdefender-dump.py after I've mounted the AD1 image with the FTK Imager.
When perfoming this operation on Windows - under no circumstances turn the Windows Defender off. Use the directory exclusion because they will keep being qurantined :)
Crypter (intel.exe)
Let's analyze what it is doing (dotPeek).
CTF Safeguard (do not run on the CTF participant system if mistakendly run by one).
Generate user/faction ID (it is visible on the ULTIMATE.hta).
Create CoreEncrypter object.
Iterate recursively over all directory entries and run the encryption on files, unless they don't qualify for encryption.
At this point we are ready to write decryptor. "Missing" part is a Faction ID we have obtained from the ransom note.
using System.Text;
using System.Security.Cryptography;
conststring salt = "0f5264038205edfb1ac05fbb0e8c5e94";
conststring UID = "5K7X7E6X7V2D6F";
var filePath = "Applicants_info.xlsx.korp";
var password = GetHashCode(UID, salt);
DecryptFile(filePath, password);
voidDecryptFile(string encodedFilePath, string password)
{
if (!encodedFilePath.EndsWith(".korp"))
{
thrownew ArgumentException(encodedFilePath);
}
byte[] buffer = newbyte[ushort.MaxValue];
var rfc2898DeriveBytes = new Rfc2898DeriveBytes(password, newbyte[8] { 0, 1, 1, 0, 1, 1, 0, 0 }, 4953);
var rijndaelManaged = new RijndaelManaged();
rijndaelManaged.Key = rfc2898DeriveBytes.GetBytes(rijndaelManaged.KeySize / 8);
rijndaelManaged.Mode = CipherMode.CBC;
rijndaelManaged.Padding = PaddingMode.ISO10126;
rijndaelManaged.IV = rfc2898DeriveBytes.GetBytes(rijndaelManaged.BlockSize / 8);
using (var encodedFileStream = new FileStream(encodedFilePath, FileMode.Open, FileAccess.Read))
{
var decryptedFilePath = encodedFilePath.Replace(".korp", string.Empty);
using (var decryptedFileStream = new FileStream(decryptedFilePath, FileMode.Create, FileAccess.Write))
using (var cryptoStream = new CryptoStream(decryptedFileStream, rijndaelManaged.CreateDecryptor(), CryptoStreamMode.Write))
{
int count;
do
{
count = encodedFileStream.Read(buffer, 0, buffer.Length);
if (count != 0)
cryptoStream.Write(buffer, 0, count);
}
while (count != 0);
}
}
}
stringGetHashCode(string pass, string salt)
{
var password = pass + salt;
using (var cryptoServiceProvider = new SHA512CryptoServiceProvider())
{
byte[] bytes = Encoding.UTF8.GetBytes(password);
return Convert.ToBase64String(cryptoServiceProvider.ComputeHash(bytes));
}
}
Running the code against the encrypted XLSX file yields restored file. Because I don't want to deal with the potential malware in the XLSX file - I unzip the file and uses Visual Studio Code search functionality to grab the flag.