Challenge Points: 998 No. of solves: 3 Challenge Author: Azr43lKn1ght
Challenge Description
Damian Wayne stored a secret in his old pc, but Dr. Simon Hurt who got this information, planned a contingency against Damian by the help of Starlab’s techies, poor Damaian was so eager to view the encrypted secret file that Raven sent him long back but Simon knows this piece of information as well as the decryption process, will he win this situation like a Wayne? will Damaian’s Redemption be successful!?
Volatility Foundation Volatility Framework 2.6.1 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win7SP1x64, Win7SP0x64, Win2008R2SP0x64, Win2008R2SP1x64_24000, Win2008R2SP1x64_23418, Win2008R2SP1x64, Win7SP1x64_24000, Win7SP1x64_23418 AS Layer1 : WindowsAMD64PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/mnt/e/writeup/bat1/Damian.mem) PAE type : No PAE DTB : 0x187000L KDBG : 0xf8000280f0a0L Number of Processors : 6 Image Type (Service Pack) : 1 KPCR for CPU 0 : 0xfffff80002810d00L KPCR for CPU 1 : 0xfffff880009ea000L KPCR for CPU 2 : 0xfffff880030a8000L KPCR for CPU 3 : 0xfffff8800311d000L KPCR for CPU 4 : 0xfffff88003192000L KPCR for CPU 5 : 0xfffff880031c7000L KUSER_SHARED_DATA : 0xfffff78000000000L Image date and time : 2023-05-06 16:45:20 UTC+0000 Image local date and time : 2023-05-06 22:15:20 +0530
now let’s get the list of processes running on the system.
this is the only thing that looked suspicious as it spawned our malicious process.
this looks self modifying as well there seems to be a control flow change as well, but after few analysis there doesn’t seem to be any malciious activity.
let’s get into analysis of the process scvhost.exe’s binary
we can see that the binary is packed with UPX packer.
so let’s unpack it
Looking at the strings of the binary gives us some suspicious output, like
so we will better start analysing it statically with ida.
This initial bit seems straightforward, it’s checking the privilege with which the current process was launched. If it was launched as admin, then it proceeds, else it executes runas svchost.exe, which is standard to elevate privileges.
here we can see that PEB is being meddled with unlinking the current process from the list using SeDebugPrivilege just like how prolaco malware does. in simpole words we can see that this is taking off the link to the current process from the previous node in the process list, and is making it point to the next process in the list. (processes in Windows are stored in the form of a linked list. So a process can be “hidden” by simply unlinking the “next” pointer from the previous process in the list and making it point to the one after the process we wish to hide).
So this function is simply to unlink the process from the process list.
Next, inside both blocks of the if-else condition, lies this function
This function is simply to hide the process from the task-manager list
Next, we have this function
What this function does is, it sets the “priority-class” of the current process to “low”, effectively rendering it as ignored by the system unless and until it has no other jobs to perform. Coincidentally, this also does a good job at hiding the current task.
These if else condition blocks are based on the response given by the user after the UAC (User Access Control) prompt is generated after runas svchost.exe is executed.
Next up we have a plethora of anti-debug checks, which can be easily found by just visiting the function calls from here
so we have to either patch it or bypass it if we have to debug it.
The next function simply creates a Notepad.exe process
Now let us analyse this block
K32EnumProcess is a Windows API to enumerate through all running processes on the system, and it retrieves an iterable with the PIDs of each such process.
Keeping this knowledge in mind, we can make a good hunch saying that this is enumerating through the PID list of current running processes to try and find the PID of the Notepad.exe process that was just created prior. This is backed by the fact that it is iterating from 0 to the highest PID there is, and storing those in a variable and making a comparison against Notepad.exe. Hence, moving on.
Next, it gets the handle to the environment variable AZRAEL After that, it XOR encrypts the content that the environment variable points to with the key 0x33, and stores that in an array.
let’s get the value of the environment variable AZRAEL
After this, it opens a file in “read bytes” mode, called confidential.bin, and writes it in “write bytes” mode to another file called windowsupdate.bin.
trying to dump as well as retreive both the files end in a failure as well mft has no data as well which might be because of aes encryption charset issue eventhough the file is not more than 1024 bytes long.
Next up, it takes the encrypted environment variable that we have, then performs an AES decryption using that as the key. We know that it is AES-ECB by looking at standard AES operations being performed in the binary, such as sub_bytes and substitution.
Also another dead giveaway is that it is being performed upon multiples of 16 bytes each
This AES decrypted data is then taken and put through another encryption scheme, namely
This seems like a pretty simple encryption, since we already have all the runtime values of the keys and values being used here (key depends on the value that we set the AZRAEL environment variable to) A decryption algorithm for the above encryption would look as follows:
1 2 3 4 5 6 7 8 9
int a=1; for (int i = 0; i < size; i++) { plaintext[i] = plaintext[i] ^ env_var[i % encsize]; plaintext[i] = plaintext[i] - ((i + a) % 10); plaintext[i] = plaintext[i] ^ env_var[i % encsize]; plaintext[i] = plaintext[i] - ((i + a) % 10); a++; }
This next block we can see
VirtualAllocEx, WriteProcessMemory, GetModuleHandleA(“Kernel32”) are all very very common indicators of a DLL injection being undergone, and in our case, the DLL being injected is Msvrct.dll.
After injecting the dll, the malware seems to be going on a spree of deleting a bunch of windows registry keys clearing forensic evidences, trying to cover up all evidences of its actions. It even deletes confidential.bin, and then deletes any evidences of itself having deleted it.
This is trying to delete a subkey named Notepad.exe under the key opened right before this. The registry keys for this handle are deleted both under the 64-bit and 32-bit mode - as some applications might have separate entries open for both architecture modes.
Furthermore, specific files from the Windows file system are targeted and removed based on their relation to user activity logs (in this case our malware), history, or cache files.
as well we can see that the encrypted strings not unallocated or flushed.
so we have two ways to get the flag here.
as we know the encrypted content from teh file ois decrypted and then goes through the encryption algorithm of xor and shifts, so we can give the flag format into it , which gives us “`q2sWRN”. then we can dump all the vads/heaps of the process and grep from them/ do a search for it or we can get them from the vads listing easily by using Memprocfs
we can patch the binary to bypass the anti-debugging checks and then debug it to find distance from some known address to the encrypted string heap address with a pointer in the stack where as of now we know the key or setting up a decoy key in our debug environment and finding the distance between the key and the pointer to the encrypted string and with that we can get the address of key and then the encrypted memory, list all the mapped memory and get the encrypyted 60 bytes using this way.
by either of the method, we get the encrypted string
Thank you to everyone who tried the challenge and congratulations to the 3 teams who solved it: idek, kalmarunionen and C4T BuT S4D. We thank you for playing the CTF and would love to hear some feedback about the challenge. If you have any queries regarding the challenge, feel free to hit me up over twitter/discord.
