Introduction:
We were able to get our AWS client working with some outside help, and will be using the ThreatAnalyzer to deploy any malware samples we submit. Once it is finishing analyzing the malware, ThreatAnalyzer will then create a detailed report for us. This report serves as an excellent reference while we do some static and dynamic malware analyses of our own, and it gives us an excellent starting point to start looking within our Threat Analyzer Client. We feel that it is best to get hands-on experience analyzing the malware because it will be easier to learn this way, as well as possibly allowing us to find other artifacts.
We found some pre-written Yara rules online and added them to VirusTotal Intelligence. The Hunting tool in VirusTotal allows us to submit rules, then VirusTotal will display a notification if any new malware samples are submitted that match up with those Yara rules.
From the repository of malware samples we now have, we choose to look at an NJRAT, which is a remote-access Trojan that has been used for the last two years. We submitted the malware sample to ThreatAnalyzer, but have not run the malware yet. Instead, we downloaded it onto our client machine and did some static analysis on it using a variety of different tools. So far we have come up with some interesting results; including that in the malware’s code there are functions written that are being called to find any malware analysis tools running and kill them. An easy way to get around this is to rename the tools, and the malware shouldn’t be able to tell the difference. There were also many suspicious strings revealed to use in Detect It Easy (DiE). The malware doesn’t seem to be trying too hard to hide itself. All this useful information gathered is why it’s always good to perform static analysis before dynamic.
We also reviewed a fake Adobe Flash Player update that ended up giving us a lot more results than we previously expected. Initially, we thought this sample was just a form of dropper malware that downloaded three different executable files called Trojan.exe, Stub.exe, and Server.exe. The latter two seemed to do little to nothing of value, but still embedded themselves deep within the file system within Temp folders. Trojan.exe however seemed to launch a keylogger, we were even able to locate the text file the program was using to store the data it logged.
Tools:
Within this project we are using different malware analysis tools. Below is a list of several tools we have been working with the most over the last few weeks.
- CFF Explorer
- DiE
- SysInternals Suit
Compromised Websites
We were able to find a list of thousands of websites that appeared to be compromised. These sites will redirect you to “Arpanet1**7.com”, we have decided to conceal the full name of this website because it will attempt to download malicious software to your system.
We encountered the virus on “www.aspirationsda**e.com” which appears to be a legitimate website for a dance studio. We chose this website randomly from a list of thousands of compromised sites which includes popular free movie and tv show streaming sites. As well as other common sites that you may encounter. Once downloaded, you will be prompted to install the fake “Adobe Flash Player Update”. This appears to be legitimate, but will actually drop the malware on your system.
Adobe Flash Player Dropper Malware:
This nasty piece of work was hidden in plain sight. As previously mentioned the malware was disguised with other file names, but also a peek into the registry lookups it performed revealed another interesting set of actions. The registry was queried several times after the software was installed for names like, AVG, Norton, and BitDefender. This means that it was looking for the registry entries of anti virus software that had likely detected it in the past.
Static Analysis
Before running the malware, we performed a static analysis using CFF Explorer. We were able to identify that the dropped file was a 32-bit Executable. It was developed using EmEditor which is an extensible commercial text editor for Microsoft Windows.
Using DiE (1.01) we were able to find that the dropped executable has an Entropy above 7.2. This is a fairly high level of entropy and would suggest that the file is Packed. This means that the file has been modified using an encryption or compression program. This is a very common way to repackage known malicious programs to avoid detection by malware scanners.
Network Activity
Once the executable is run, a GET request for scanner.php is sent to the Arpanet domain. This is all handled by a script on the website that drops the executable. The file is referred to as scanner.php. This script analyzes the browser for a timestamp and a region, which makes it likely for the default language in the installer to make the file seem more legitimate.
Below is a breakdown of scanner.php
Keylogger Analysis:
Our Adobe Flash Player Update malware sample provided a various amount of interesting results. Upon running the malware within our Threat Analyzer Client workspace, the initial install and download of the “update” seemed rather normal in terms of what an actual update of this software looks like.
Using Process Monitor, we were able to view the process the downloader created, as well as the malicious one it created called Trojan.exe. The program seemed to be running command via Windows Command prompt that was attempting to add a firewall exception to the file location of the malware. Process Monitor allows us to look at the malware in memory if it doesn’t ended up killing itself after it executes. Other times a malware will fail to run if it detects certain software it deems might interfere with its proper execution. Tools like Process Monitor, Wireshark, as well as the SysInternals Process Explorer provided by the SysInternals Tools Suite are normally high on the list. In order to attempt to circumvent any issues we might have with that, we chose to rename both those programs to something random to avoid detection.
Seeing this command being run prompted our team to open Wireshark to see if any outbound signals could be captured, Generally, we found the connections of our RDP (Remote Desktop Protocol) client hosting this malware sandbox. Among the signals, we found an attempted connection to a completely new IP Address trying to reach out through a random port. It was trying to reach 172.31.51.202 through port 51647, but we were unable to find out what data it was trying to transmit or why.
Later, we decided to follow the path we viewed within the command Trojan.exe was trying to run, a temp file whose location was C:\Users\Administrator\AppData\Local\Temp\2\Trojan.exe. Within this directory we found a text file with everything we had done within that workspace since we executed the initial Adobe Flash Player Update malware. Near the top of the list was a log of our Wireshark scan that we had just conducted.
This key logger was also able to log our access to the internet, at one point we logged back into Virus Total to search for the hashes of the other files that were dropped and it caught all of that.
The final test we did to confirm this was open a new Notepad and simply type something into it to see if it could also measure key strokes. We found that it could indeed do that, allowing us to confidently label this a keylogger.
To Come:
We plan to find/write even more yara rules to submit to VirusTotal. We would like to perform dynamic analysis on the NJRAT and see what information we can gather from there. We also recently learned that a new version of the Mirai Malware has been released, and it would be interesting to look into that. Now that we have some good samples of malware to look at we will be analysing and writing up many more formal reports.
Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at lcdi@champlain.edu.