Gh0stCringe (Formerly CirenegRAT)

Since early December, 2018, I’ve been seeing a new type of Gh0stRAT-like malware being distributed over SMB.  This sample has been dubbed Gh0stCringe by @James_InThe_Box on twitter.  While the network communications of this new malware is very similar to that of Gh0stRAT, there are some key differences: Instead of the use of Zlib compression on the data, the sample typically uses an encryption algorithm consisting of Xor and Add, or Xor and subtract.  Additionally, the sample uses much less commands than Gh0stRAT and seems to serve as more of a stage 1. Features include:

• Encrypted traffic using its own protocol
• Ability to open a proxy
• Clear event logs
• Leverage iexplorer.exe to open Urls

Malware communicating its login packet to my server

Actors

Similar to Gh0stRAT, I believe that this sample is shared between many actors, as I’ve seen many different predominantly Chinese threat groups using it.  For example, the actor’s behind IndoneMiner have been seen using it.  Additionally, I’ve seen MadoMiner’s actors using this RAT, along with many different campaigns, which will be discussed more below.  

Campaigns

In December 2018, I began to see a new type of RAT distributed over SMB using ZombieBoy’s exploit tools.  On account of the use of reverse string encryption in order to drop the payload, I began calling this RAT CirenegRAT.  Based on the domain used for distribution, this will be the indexsinas campaign.

Indexsinas domains/C2s

Distribution: 114.31.36[.]202:8111, 1.indexsinas[.]me:8111

C2(old): dllhost[.]website:8093

Filename: x8.exe

Service: serviecs

Service Display Name: System Remote Deta Simulation Layer

Mutex: dllhost.website:8093:serviecs

Note:  It seems that this actor has since changed the RAT used in their stage one.

MadoMiner

The next campaign that I saw using this RAT occurred around Feburary 12th.  @James_InThe_Box had discovered a version of the RAT being distributed off t.honker[.]info.  If you’ve read my Madominer Analyses (part1, part2) on Alienvault, you’d recognize that that domain looks very familiar.  I’d written about malware being distributed from d.honker[.]info, so imagine my surprise when I found that the Madominer actors had shifted to using t.honker[.]info to distribute their new payloads.  While nothing else had really changed, Gh0stCringe was added as the new stage1/loader for MadoMiner. Additionally, they’d gained a new mining address of 42SgGCdjazjddK45L9AQGyXwZPh7VRRPW47iWG18uvFdQ7sXMAHgnDd1e8pHdu68AHbSaYo2a7x6QCSRjGeM14oZ1RSLVRi, mining on minexmr.  While this address has since been taken down, it should be noted that it was pulling in 219KH/S, or $3240/month.

Distribution: t.honker[.]info:8/

C2:sky.hobuff[.]info:8008

Service:  ctfmon

Service Display Name: System Remote Data Simulation Layer

Mutex:sky.hobuff.info:8008:ctfmon

IndoneMiner

In January, the Tencent Yujian Security Research center wrote about a mining campaign that they’d nicknamed IndoneMiner.  A little bit after I discovered the MadoMiner Gh0stCringe, I began to see a VmProtected file dropped on my honeypot. Analyzing the file, I saw that it connected to http://indonesias[.]me:9998/cc64.exe in order to download and execute the file cc64.exe.  Upon closer examination of the file in question, I saw that this file was also a version of Gh0stCringe, however, it appeared to be a newer variant.  This variant appeared to have less functions than the original, but used stronger encryption on the base strings. Additionally, it was missing the functions that variant 1 would export for use.  

Distribution: indonesias[.]me:9998

C2: http://indonesias[.]website:5814

Service:RpcEpt

Service Display Name: Remote Access Routing Manager

Mutex: indonesias.me:9998:RpcEpt

Office.exe

Recently (May 4th), @James_InThe_Box sent me a sample that he believed was Gh0stRAT.  Upon closer examination however, this sample appeared to be a variant of Gh0stCringe, similar to the variant used by the IndoneMiner gang.  This variant, like the Indexsinas campaign was distributed from an Http File Server, which seems to mainly be used by Chinese actors.

Distribution: 106.13.96[.]196

C2: 106.13.96[.]196:8090

Service Name: EventSystem

Service Display Name:  Com+ EventSystem

Event Name: Null/:Ma

Mutex: 106.13.96.196:8090:EventSystem

Functionality – indexsinas

This RAT’s functionality appears more focused on serving as a stage1 than taking control of a victim’s computer to perversely monitor them as Gh0stRAT has been known to do.  Instead, this RAT appears to install to services and then wait for commands to download and execute more malware. Additionally, with the exception of the indexsinas campaign, this malware appears to exhibit some fileless capabilities, as it loads its payload into memory to help avoid analysis.  With the indexsinas campaign, the malware would save its payload to %Windows%System32, which it would use to call the install function, from the functions exported below

In the indexsinas campaign, the malware has 5 functions that it exports

• DllUpdate
• Install
• MainThread
• ServiceMain
• Uninstall

It would use all of these functions in its runthrough/command acceptance.  

Install

This function was the first function called during the payload’s runthrough.  As its name would suggest, it was designed to install the payload to the system.  This function behaved very similarly to the Shellex function (described below), in which it would push it’s variables to the stack, like the Service name/Display name.

The main functionality of the Install function was to install the payload DLL as a service, using the svchost system process.  The Image Path was set to %SystemRoot%System32svchost.exe -k “serviecs”, while the Service DLL was set to the Malicious DLL. After installing the malware, this function ends and it hands off control to the ServiceMain function

ServiceMain

After confirming that the service is installed correctly, the malware obtains RunDll32.exe (which is by default stored in %SystemRoot%system32), copies it, and saves it as [service-name].exe(serviecs.exe).  Next, the malware grabs the SYSTEM user’s token and uses that to escalate privileges with “serviecs.exe serviecs MainThread”, in order to run the MainThread function.

MainThread

The MainThread function is, as its name describes, the main thread of the malware.  This function is in charge of connecting to the C2, along with executing any commands that the C2 sends back.  

First, the dll creates a new mutex using the service name, which in this case is “serviecs”.  It then obtains the connection information from the mutex created in the loader, which it uses to attempt connection to the server.  Just like in Gh0stRAT, the malware doesn’t wait for verification that the server connected to is actually its C2. Instead, the malware instantly sends over computer information, like so:

Some of the information stolen:

• Computer Name
• Malware Group ID (x8)
• Date Installed
• CPU Write Speed/Processor Count

Additionally, there is a proprietary protocol which has remained relatively unchanged, and will be described more in depth in the “Networking” section of this analysis.

Commands(x8):

With opcode 0x07, there is a command called Update, which uses InternetOpenFileA/InternetReadFile in order to download an exe(uses a check for the EXE magic number, 0x5A4D), which is then written to a buffer of memory.  The malware is then updated using the DllUpdate function.

DllUpdate

The DllUpdate function first creates a backup of the current malware version, before creating a new process of the file to be updated with the commandline “Gupdate [service-name]”.  This command replaces the current malware version with the malware downloaded in the Update function.

Uninstall

This function may be the reason that the actors behind Gh0stCringe have moved away from the multiple exports used in later variants.  When this function is called, there are no traps, instead, it completely uninstalls itself from the system. Coincidentally, since this was an export, and not a typical function which is located by the malware, you can call it at anytime using either the dropped and renamed Rundll32.exe, or just using normal Rundll32.exe.  If using Rundll32.exe, the format for the uninstall command is “Rundll32.exe [malicious dll].dll Uninstall”.  By running this command, x8.exe and the malware installed as a service will be uninstalled.  

Persistence

Additionally, for persistence, the malware leverages svchost and ServiceDll for service installations.  Instead of just installing itself as a normal service, it uses its dropped dll to install itself as a service group so that it is spawned by svchost using svchost.exe -k [service group].  This is different from normal service installations where you’ll see the malware running once executed. With this method, you’ll only see svchost running, as it loads the dll that is used into memory.

Functionality – current variants

With current versions of the malware, the only function that it exports is typically a function called “Shellex”, which basically combines Install, ServiceMain, and MainThread.  Additionally, the Uninstall function has become a function contained inside the malware instead of the export that it was in the indexsinas variant. Also, instead of dropping a dedicated malicious DLL, the malware loads the DLL into memory, and installs itself in such a way that the loader exe is opened on each service open.  

Additionally, the commands used by the other variants have decreased, as seen below

Persistence

For persistence, the newer variants will just install themselves as normal services, with none of the special service group techniques.

Networking

As mentioned above, the malware uses a custom proprietary protocol, similar to that used by Gh0stRAT, however, there are some key differences.  The protocol in Gh0stRAT uses zlib compression on the traffic, while Gh0stCringe is missing that. However, that doesn’t mean that Gh0stCringe just displays the information that it steals in clear text.  Gh0stCringe uses an Xor/Add or Xor/Subtract algorithm to encrypt all of its traffic. Interestingly, for several of the variants, while the actual Xor/Add and Xor/Subtract values were different, they all produced the same value.  

Additionally, the protocol format is a bit different than Gh0stRAT’s, as shown in the below image:

Currently, I’ve only seen 3 opcodes used for responses:

Old Variant

New Variant

Mitigation

As Gh0stCringe is typically spread using EternalBlue, you’ll first want to make sure your systems are patched for MS17-010.  This will help you to avoid getting infected, which is the best form of mitigation.

If you are hit by Gh0stCringe you’ll need to follow this guide in order to uninstall it.  First, you’ll want to disconnect the infected computer from your network in order to properly triage it and to prevent further infection.  Next, using the sysinternals tool WinObj, you’ll want to locate the mutex of the running malware. This mutex should be easily identifiable, as it’ll consist of [C2 URL]:[Port]:[service name].  

Once the mutex is located, you’ll want to navigate HKLM/SYSTEM/CurrentControlSet/Services to look for the service obtained from the mutex.  For example, if my mutex was dllhost.website:8093:serviecs, I’d be looking for a service titled “serviecs”. For the older variant of the malware, you’ll need to locate the ServiceDll value, located in [Service Name]/Parameters.  This will tell you the location of the malicious DLL. For the newer variant of malware, you’ll want to look for the ImagePath value, stored in the [Service Name] key, as this will tell you the location of the malicious exe.

For the newer variant, once this value is obtained and the malicious exe is deleted, you’ll want to delete the service registry key and close any open processes for the malware that you can find.  You’ll then want to restart the computer.

For the older variant, unfortunately, your work is not done.  After deleting the malicious DLL, you’ll want to take a look at the ImagePath value in [Service Name].  This will tell you the service group that the malware has installed to. You’ll then need to navigate to HKLM/Software/Microsoft/Windows NT/Svchost/ key and delete the service group value that corresponds with the service group that you found found in ImagePath.  For example, if my ImagePath is %SystemRoot%System32svchost.exe -k “serviecs”, then the service group that I’ll want to delete will be “serviecs”.

At this point, you’ll need to restart your computer, which will finalize any changes that you’ve made.

IOCs