Aria-Body Loader? Is that you?
Hello! This is my first time writing a blog on a loader which I had gotten hold of. So, I am a new analyst in the Malware Analysis field and I am trying to do a research into cobalt strike. Recently, I ran a modified public YARA rule for cobalt strike on Virus Total and from the scan, I found two samples which I find interesting.
1e56c3f05bb53d2dfa60bc016e8509b12fd3beb5f567d274a184bb67af1eb19c
c5696e660f3cfa9232756418e40ad18729cfe32fb284bba2314dd523ba527258
These two samples have a relative large size (17.05 MB) as compared to other files and their size is exactly the same. Additionally, their upload timing is quite close to each other, around 3 minutes apart. I started to analyze the files and from my finding, it doesn’t look anything like a cobalt strike loader. Turning to my friend who have much more experience in malware analysis, I told him my findings and he told me that from what I had described, it sounds a little bit like Aria-Body instead. So I did some read up on Aria-Body and here are what I had found….
In 2020, Check Point Research release a write up (http://research[.]checkpoint[.]com/2020/nikon-apt-cyber-espionage-reloaded) describing how Naikon APT group is using Aria-body. In the report, they summarized the loader to have these capabilities:
1. Establish persistence via the Startup folder or the Run registry key [some variants].
2. Inject itself to another process such as rundll32.exe and dllhost.exe [some variants].
3. Decrypt two blobs: Import Table and the loader configuration.
4. Utilize a DGA algorithm if required
5. Contact the embedded / calculated C&C address in order to retrieve the next stage payload.
6. Decrypt the received payload DLL (Aria-Body backdoor).
7. Load and execute an exported function of the DLL — calculated using djb2 hashing algorithm.
Take note on these points as I will be mentioning some of them in this post.
Analysis of the samples
As I had mentioned in the intro, the first thing that I noticed about the two sample is that both of them have exactly the same size. When I loaded them into PE studio, I noticed that they share the same compiler, debugger and exports timestamp.
Now looking at the section’s metadata, we can see that all but two of them have the same hash. The two sections with the different hash is the .text and the .data section. Although they have a different hash, we can see that the raw-size, virtual-size, raw-address and virtual-address are the same.
Looking into the import and export section, this two samples also have a same import and export.
Looking at the static properties analysis, these two files seems like twins. They could have the same origins or they might be built using a builder. But this is just my speculation at this point as there are not enough information to support the claim.
Looking for the “action”
Now that I had done the analysis on the files properties and confirmed that it is a 64 bit DLL, it’s time to throw the sample 1e56c3f05bb53d2dfa60bc016e8509b12fd3beb5f567d274a184bb67af1eb19c into IDA for analysis. After IDA has finished loading, the first thing that it displayed is this:
That’s all ._. not helpful at all. Seems like I have to find the “action” through other means~~
Since this is a DLL, we can try to look for the “action” by checking the export functions.
From this list of 30 export functions, two of them DllEntryPoint and ILCreateFromPath caught my attention. After looking through the two functions, I had determined that the ILCreateFromPath function contains the “actions” that we are interested in.
Obfuscation
While scrolling through the ILCreateFromPath function, I noticed a pattern:
Noticed that the value “]prt-.p,^p,0tnpN.,wSlyowp,b” in the variable aPrtPP0tnpnWsly was lea into rcx followed by calling the sub function sub_180001010 then followed by a call rax. From my analysis, the function sub_18001010 consist of two parts.
1 — Decode the string
First it will decode a string that is passed in as argument which in this case is the value in the variable aPrtPP0tnpnWsly.
This function decodes the characters by applying the concept of Substitution cipher where it takes the ASCII value of each character, add 28 follow by mod 81 and finally add 42. This is the formula for the substitution cipher that I had just describe: plain_text = (cipher_text + 28) % 81 + 42. Thus, the value of variable aPrtPP0tnpnWsly decodes into RegisterServiceCtrlHandlerW which is a Win32 API.
Using this formula, I wrote a simple python script to do the decryption and ran it on all the strings found in the same data section as aPrtPP0tnpnWsly and here are the decrypted strings:
Looking at the de-obfuscated strings, it seems like they are hiding function calls in strings and decode them during runtime so that we cannot most of its capabilities just from looking at imports table. From the list of the De-obfuscated strings, we can see that some of the capabilities of this malware includes creating thread and writing into memory.
2 — GetProcAddress
Once the string is decoded, the function will then call LoadLibraryA and GetProcAddress before returning the address of the call.
Alright, now that we know that this malware has the ability to hide its function calls what’s next?
Threading and New Processes
Following down the ILCreateFromPath, I saw that the malware creates a new thread to execute the function called StartAddress.
So the only thing to do is to follow and look at what does the StartAddress function do.
Looking through the StartAddress function, the first thing that caught my eyes is a variable containing the string “%s\\dllhost.exe /Processid:{%s}” followed by CreateProcessW. It looks like the malware is trying to create a dllhost process.
After calling CreateProcessW, the malware then proceeds to call VirtualAllocEx followed by WriteProcessMemory.
From the above code, we can see that the malware used the WriteProcessMemory function to write the function sub_181064570 into dllhost process created earlier. Although this seems to be a common process injection, it matches the checkpoint’s report, where it mentions that it injects itself to another process such as rundll32.exe and dllhost.exe.
Decoding Embedded Data
Finally, we have reached the part where we can see what this malware actually wants to do! This is how the first few lines of the function written into the process’s memory looks like:
It looks like the malware copying two sets of data located at qword_181065CC0 into the memory.
After copying the data into the memory, the malware calls a function which will decode the data.
The first blob of data contains the URL of the C2 server “news.nyhedmgtxck.com” and a string of characters which doesn’t seems to be used in any part of the execution.
And the second blob of data contains the imports table which the malware will use in the next phase of its activity. Wait a minute… does the 2 blobs of data sounds familiar?
From checkpoint’s report on aria-body loader, they mentioned that one of the functionality of the loader is to decrypt two blobs of data into an Import Table and a loader configuration.
Download and execute payload
By using the decoded import tables, the malware attempts to connects to the C2 URL to download a file.
To this point, it actually matches the points mentioned in Check Point’s report where Aria-body contact the embedded / calculated C&C address in order to download retrieve the next stage payload.
Too bad for us, the URL has already been sinkhole. Therefore, I am not be able download the sample for analysis ):
It’s not the end yet! Although I am not able to analyze the next stage payload, I am still able to see what this loader does before passing control to the next stage payload :D
Once the payload is downloaded, the malware will first decode the payload with a XOR function. The decoded payload will then reside only in the memory. Which suggest that it could be a file-less malware.
Next, the malware then calls a function which checks if the payload contains the magic number “MZ” and “PE”.
Once verified, the malware will finally get the entry point to the payload by calculating the djb2 hash of the payload’s export and comparing it with 0x2E9AD5FB. Without the second stage payload, I am unable to determine what is the export name based on that hash.
Finally, the malware then passes the execution control to the payload.
The way this malware get the entry point also matches what Check Point had described where the loader loads and execute an exported function of the DLL — calculated using djb2 hashing algorithm.
Conclusion
Phew… Finally! We’ve reached the conclusion~~ v^^v
From the analysis, this malware looks like a loader which will download a payload from the C2 and execute the payload on the memory. The capabilities of this sample is very similar to the Aria-body loader that is described by Check Point where 5 out of the 7 points matching the analysis. I am unable to determine if this sample “establishes persistence via startup folder or run registry” and the “utilization of the DGA algorithm”. Putting the capabilities aside, I had look through the sample with the hash “40c49ecbe1b7bdodbb935138661b6ca4” mentioned in Check Point’s report and code wise, it looks vastly different from this sample.
Noticed that up to this point, I have only talked about the analysis of one of the samples. Well, I had done the analysis on both of the sample and in regards of the code executions, they are the same. The only difference between the two sample in regards to what is relevant to the execution and its function, is that the C2 string and the string of character in the first blob of data is different. Instead of going to “news[.]nyhedmgtxck[.]com”, the C2 of the other sample is “www[.]etnwtmrkh[.]com” both of which are sinkholed.
Therefore, based on the capabilities, am I right to say that this could be a variant of Aria-Body loader?
Hashes Analyzed:
1e56c3f05bb53d2dfa60bc016e8509b12fd3beb5f567d274a184bb67af1eb19c
c5696e660f3cfa9232756418e40ad18729cfe32fb284bba2314dd523ba527258
