Introduction
I have recently been interested in fileless malware and the different approaches authors have when executing them. I hope to study them to see what they can soon evolve to be and possibly create my very own, but in the meantime, samples like the one I will be analyzing here are enough for my curiosity.
Fileless malware is a type of malware that writes nothing to the disk but rather executes data in the memory. This makes it hard for detection systems to detect them and they typically use trusted applications such as PowerShell to run them. Doing things such as executing a Trojan, clicking the wrong link, or visiting a webpage can have severe consequences for your computer. Fileless malware also makes it hard for forensics investigators to do their job as they rely on more persistent forms of data to gather concrete evidence in a case. Memory/RAM is much too volatile and easily corruptible and reliable. Poweliks is a fileless-based malware that acts as a dropper and uses the registry to self-install itself if it is deleted. Doing some research online I found it to be a click fraud Trojan. It sends ads to the victim’s PC. This malware also acts as a dropper, and I from my research, I believe that some light spying was done as system information seemed to be sent over to the attacker while this malware was running.
Tools & websites Used
- Unpac.me
- https://en.wikibooks.org/wiki/Algorithm_Implementation/Miscellaneous/Base64
- https://gist.github.com/bcse/1834878
- IDA Pro
- x64 dbg
- PE Explorer
- RegShot
- Windows 7 32 Bit
- Virtual Box
- https://thisissecurity.stormshield.com/2014/08/20/poweliks-command-line-confusion/
Initial Analysis
Initially, I looked to see if it was packed. From running strings on it, I believe that it was packed based on the way the data appeared. It was all obfuscated with no detailed string except for the import table. There was no readily identifiable packer tag, so I decided to go with this website I know called unpac.me. One that uses AI to unpack malware automatically.
Here I got three unpacked children from this one sample. I started with the second sample, the one which starts with 9537c. For clarity I will call this unpacked_child_1.bin.
Unpacked_child_1.bin Analysis
First analyzing it for strings I found the following IPs along with other data.
So I now have some network indicators that can be used to identify this malware sample. This malware also appears to have a self-deletion feature in it and something shared in most malware. Since this is dropper and fileless, leaving without a trace would be best.
Other Indicators I found for detection were its opening of the event of b8b01eef934b. Can be used a host based indicator in future strains if this same event if used.
Sub_401595 Analysis
This subroutine is where the network operations are being done in terms of informing the attacker on the progress of the malware itself. It takes in the following for its second argument:
- Start
- Exist
- Low
- Install
- Error_%u_%x_%x - This appears to be error handling
Here the header information is being created. I know from previous analysis that the Method here is POST. Meaning data is being sent over to the attacker here. I was able to determine that System information such as if the computer is 64 bit or 32 bit is being sent over.
Sub_401BF5 Analysis
This routine is where most of the persistence, dropping is essentially being done.
This PowerShell script is captured here. Deobfuscated it
My belief of what this code is doing is that it is executing some form of other shell code which will be passed on to it from possibly another part of the program. The Function Ga is acting like a wrapper for the function GetProcAddress. Fn the parameters of the name of the dll and the name of the function it returns that method. In this case, the methods being used appear to be VirtualProtect, which changes the execution status of memory and CallWindowProcA. I believe that it is getting these areas ready and then executing the shellcode which will be passed on to later.
Moving on data which I believe to be shell code is encoded and later decoded and used by this these functions to execute.
The malware authors decided to manually create the base64 encoding procedure. Luckily based of the charset they used it was easy to understand and verify what they were doing using a quick wiki search of the base64 algorithm. This data is copied to an allocated buffer and then later decoded and used by this malware for execution.
This code was significantly obstructed before cleaning it up, but it was easy to read once done.
First, the URL being used should be noted. http//faebd7.com/log?log=1. I was able to find now additional on this URL using WayBackMachine, but it is definitely something that should be recorded in case of future activation. One thing that was unique about this URL was that it was just a hex color. This makes me think that this malware or its strains might be using randomly generated URLs. It’s possible to avoid detection.
Next, I noticed the PowerShell Path being specified. Also, the variable x is set to the Msxml2.ServerXMLHTTP.6.0 object is being used to grab data. This data is then written to a file, deleted but not before being run. So while this malware is said to be fileless and trying to leave no traces, it is a little sloppy and allows for its actions to be tracked.
Trenching Onwards
The following URLs are found. This step is very important. This malware is detecting if PowerShell if on the host computer. Along with the computer information it gathered about it the victim PC being 32 or 64 bit, it is able to download the right version of PowerShell and then to execute. This is a common trait with post malware, so simply deleting PowerShell isn’t a great solution for avoiding these types of attacks.
Here we see persistence is achieved through the registry. Since data is being written here this malware isn’t truly fileless, but as the evolution of fileless has become apparent, we know that fileless is taking on a new approach to sticking around even after reboot. The behavior here must be analyzed through dynamic analysis.
Dynamic Analysis
The Following were round in the registry of:
- HKCU\software\microsoft\windows\currentversion\run\ directory.
Script is the next registry element which is read from on the next entry of the registry directory show in the next screenshot.
Since it is encoded, I looked online for a JScript decoder to see what was inside of it. I will also link this in this write up.
Decoded
The encoded data found on the bottom was more of the decoded data I found before. So basically, all this is doing is achieving persistence and rerunning itself in the event that it is deleted in any way. This check is seen every time the computer is rerun.
Summary
Because the URLs can’t be reached, the full function of this malware no more works, although it can easily be repurposed in the future. While it has been documented that it is an Adware fileless malware, I will take that as fact, but because of the evidence of log files and the naming conventions of the URLS as well as the information that is being stolen from the computer, I believe that parts of this malware also have to do with espionage. Nothing extreme but at least to determine what type of computer the target is.
Simply deleting the registry entry and restarting your computer should be enough to stop this malware since it doesn’t appear to be achieving persistence in any other fashion.
This malware did not seem to have anti-anti-VM or debugging tricks and unpacking it quickly. I think the way it achieves persistence was sloppy, and it made to much noise and left tried to hide pieces of itself through file deletion. This still makes it susceptible to logs in the future and should be rethought about for anyone who uses this code as a base for future malware.
💬 Comment: