Dropper SHA256: a871b7708b7dc1eb6fd959946a882a5af7dafc5ac135ac840cfbb60816024933
Backdoor SHA256: cc17391dde8a9f3631705c01a64da0989b328760e583009e869a7fff315963d7
In May, I published an analysis of the persistence mechanism for Mars-Deimos and had intended to publish further analysis regarding that individual sample. As a reminder and abbreviated summary, the malware that was being tracked as Jupyter started a new distribution tracked internally as Mars-Deimos. The malware is also tracked under other names: Solarmarker, Yellow Cockatoo, Polazert, and likely others.
For various reasons, I did not publish much about the Mars-Deimos backdoor, but it differed in substantial ways from its earlier predecessor Jupyter. Jupyter had been documented by a few organizations as being able to steal browser cookies and passwords from browsers. Then when Mars-Deimos replaced it in the distribution system, it did not maintain the same native functionality.
Below is an image of the functions included in Mars-Deimos. Mars-Deimos had native functionality for collecting information about its host and encrypting the information and submitting it back to the Command and Control server (C2). It also had functionality to download and execute code.
I documented some of this information privately, but did not publish regarding it. Now that Mars-Deimos is being replaced, I want to publish some about it for historical reasons, but those functions are not an immediate threat.
Additionally, in the time since my last blog post, I’ve spent time looking at their distribution system and am documenting it privately. My goal with this article is to write some about the distribution system as well as mention the current functionality.
Distribution:
To make a long story short, the malware is downloaded the following way:
A victim googles for a template of a document, a search result is a Google Site (sites.google.com), and the Google Site offers them a PDF or DOC version of the template.
NOTE: You’ll see randomly named documents like in the picture below: “Invoice PDF to Excel” or “Indeed Resume File Format”. All of these are completely randomized and the names don’t matter for the sake of the malware. In fact, you can change the URL and give it a custom name if you want—again it doesn’t matter—the same malware gets dropped.
The user will select to download a PDF or DOC. By clicking one of the links, the victim will be sent off of the Google Site in order to download the malware. The distribution system has features in place to also prevent users from making too many downloads.
For several months, the download page was a spoofed Microsoft website. There was a download button that would execute JavaScript in order to download the malware. Something worth noting here: for security training, users should at least be aware of the idea of Red-Flags. I believe this is a common idea in our world and it is important to apply it to cybersecurity as well in our training sessions. If they find something that seems off—like a Google Site leading to a Microsoft website—they should be encouraged to be skeptical.
The current download site is a spoofed Google Drive. The user can click the download link to download the “template” or “document” they are requesting. Many modern browsers will give a warning about the download as the browser recognizes it as an executable.
Their distribution system is very dynamic and very extensive. There are at least 60,000 Google Sites that lead to the malware and I have documented ~1,000 unique domains controlled by the authors. The URLs on the Google Site are updated through JavaScript to assign the appropriate URL to the buttons on the page.
The Binary
When the malware is downloaded, its icon is set to be that of a PDF file. The file is ~107 MB in size in order to prevent being uploaded to most automated malware analysis sites. (Most malware analysis sites which are free or paid have a size restriction of 100MB.)
The malware had previously been packed using the program InnoSetup. Unpacking the malware revealed the junk data files which the authors themselves had named “waste”.
The most recent version is no longer using InnoSetup which is a large deviation from what they have been doing for the past year and is one reason I wanted to write about the recent innovations. The most current binary is built with Delphi 7 and includes shellcode. When ran, the shellcode in the form of powershell will be executed and shortly after a Free PDF program will start and show a splash page for install. (The PDF program changes over time and is just a decoy). The following is the latest revision of powershell that is executed:
Lets walk through this. This same basic structure has consistently been used in their malware.
- Step one: set $xp to a file dropped into AppData\Local\Temp\
- Step two: set $xk to a key
- Step three: read the file $xp into the variable $xb, converting it from Base64
- Step four: delete temporary file
- Step five: decode the file $xb using the key and using -bxor through a set of two for-loops
- Step six: set the encoding to UTF8 for the variable $xb
- Step seven: execute the code from the decoded variable in memory.
At this point in time, it appears very few virus detection systems detect this behavior immediately. However, this type of behavior should be caught instantly by an Endpoint Detection and Response (EDR) system that is being monitored by SOC analysts or System Administrators. I am documenting it here so that others are aware of the activity that may be happening. Organizations should also be using a PowerShell script logging for catching PowerShell execution.
Persistence
Previous persistence was managed by changing shortcuts to call the malware when the shortcuts were executed. The last few revisions have changed this behavior. The current malware drops a file in the following directory:
"C:\Users\*****\AppData\Roaming\miCrOsofT\wINDoWS\stARt meNU\PRogrAMS\startUp\a19392f921e4f9a03b0a25110d2ab.LnK"
Due to the file being placed in this directory, it will be executed on startup and start the backdoor. EDR systems and System Administrators should monitor this directory as it is frequently used by malware.
Functionality
The current malware has stopped using the Mars-Deimos name and appears to be a different program all together. The current binary is named “F.G.” internally. The malware authors are using similar code as before to execute the malware: it is read from an obfuscated file in a temporary directory, it uses System.Reflection.Assembly to load the binary into memory, and the RUN function to execute it.
[SYSTEM.REfLeCTIon.AssEMBlY]::LOAd($af1bcb955ce42c87eb8d2346b3448); [f.g]::RUN();
In contrast to Mars-Deimos and Jupyter, the current malware appears to check to see what browsers are installed based on their default directories. If they exist, it will use System.Threading to start new threads. Based on my beginning analysis, it also appears to copy the content of forms in order to pass those back to the C2.
In contrast to previous versions, when the malware is opened in dnSpy the functionality is not completely obvious (previous versions had “Encrypt” “steal_passwords”). However, dnSpy is still a considerably helpful tool for investigating the functionality of the malware.
There is still plenty of analysis to do: if you are interested in testing your skills in deobfuscating stuff, you can get the binary from MalwareBazaar or from VirusTotal.
Detection
From reading articles about past variants, it appears that this malware can be detected by most Endpoint Detection and Response systems. The powershell execution and other features make a lot of noise. The malware also produces a large amount of traffic from a host to the C2: the current binary reaches out to Switzerland.
There are a few YARA rules which consistently detect this malware, however, I am not posting them here at the time being. Get in touch if you are interested. There are also many other tricks for analyzing this malware which I’m not sharing right now, but if you are interested in doing deeper analysis or tracking the malware yourself, please let me know.
