This article below is from CISCO. The reason I am choosing to share it is due to the fact this RAT has been around for nearly a decade or more , so many of my readers will have used this in the past. What is interesting is the way the hacker did RLO. Right to Left over-ride. Which is making the machine process code right to left instead of left to right, this method bypasses MANY “Email attachment providers”
Ding! Your RAT has been delivered
This post was authored by Nick Biasini
Talos is constantly observing malicious spam campaigns delivering various different types of payloads. Common payloads include things like Dridex, Upatre, and various versions of Ransomware. One less common payload that Talos analyzes periodically are Remote Access Trojans or RATs. A recently observed spam campaign was using freeware remote access trojan DarkKomet (a.k.a DarkComet). This isn’t a novel approach since threat actors have been leveraging tools like DarkKomet or Hawkeye keylogger for quite sometime.
Some interesting techniques in this campaign were used by the threat actor to bypass simplistic sandbox methods including use of sub folders, right to left override, and excessive process creation. This threat also had surprising longevity and ample variations, used over time, to help ensure the success of the attack.
What is DarkKomet?
DarkKomet is a freeware remote access trojan that was released by an independent software developer. It provides the same functionality you would expect from a remote access tool: keylogging, webcam access, microphone access, remote desktop, URL download, program execution, etc. One interesting thing is that it added some other functions you wouldn’t expect to try and emphasize it wasn’t a malicious tool by including a piano game and “fun manager”. Below are a couple of images of the panel that the attacker would be utilizing.
It first came to notoriety in 2012 when it was reportedly used to spy on private citizens, which prompted the creator to cease development. In early 2015 attackers took advantage of Je Suis Charlie to get victims to download and install the malicious backdoor. The latter incident coincides closely with the initial sample that Talos identified. Since that time Talos has been seeing new samples appear periodically and stay active for a relatively short amount of time. The basic functionality is discussed below.
The Spam Message
The initial campaign that started the investigation was relatively short lived with a small volume of emails. There were only a handful of messages observed sent over the course of 8 hours on a single day in June. It was designed to look like a DHL notification email trying to entice users to click the attachment to view tracking information. The message attachment was a zip file posing as an airway bill. Once a user opened the attachment and extracted it, the first layer of sophistication was found.
As shown above the miscreant placed the malicious executable inside a couple layers of subfolders. This surprisingly will work to bypass some detection technologies, including those associated with email attachment scanning. There were a couple of other interesting aspects to the email itself. Additionally, note the attempted use of Right to Left Override (RLO).
This isn’t a new technique either and is usually seen leveraging office document extensions such as slx.exe or cod.exe as seen above. At a high level RLO is a special character in unicode that is designed to support languages that are written right to left instead of left to right. This isn’t enabled by default, but if it is enabled users are that much more likely to execute the attachment since to those users the filename would be Airway_Bill 23-06-2015 Indexe.doc while actually being the malicious executable. The giveaway for this is the #U202e found in the filename. The specific unicode character required for RLO is U+202e. It seems that they failed at this implementation since Talos was unable to get it to render properly. Usually it would be visualized as a unicode character similar to what is shown below instead of #202e. This is another subtle method bad guys are using to entice as many users as possible to open executables.
Talos was able to identify multiple variants based on filename associations. We have also seen variants on the impersonated companies including FedEx. Below are a couple of the variations:
06-06-2015 Delivery Airway_Bill Index.zip
Airway_Bill 18-06-2015 Index.zip
Once the user downloads, unzips, and executes the attachment the malicious activity begins. The sample enabled driver and security privileges and then spawned the following process:
The process name AdobeARMservice.exe is designed to mimic the process used to update Adobe Acrobat Reader. This isn’t the proper path for this particular file, but it looks similar enough to other files to potentially be overlooked during analysis. Once this process was spawned a second process was spawned as shown below:
The second process bthserv.exe is designed again to try and mimic legitimate files to avoid detection. This particular file is attempting to pose as bthserv.dll which is the Bluetooth Support Service; a commonly running service on windows systems. It is this process that spawns the malicious activity. As shown above you can see a large amount of child processes with the filename vbc.exe. This process actually spawns close to 500 instances, which it turns out is the DarkKomet RAT. This repeated spawning of a process could has also been used as a sandbox evasion technique, by repeatedly starting services to try and DDoS the sandbox and make analysis difficult. There is a simple mutex identifier that is common to DarkKomet that aids in its detection. The image below illustrates this behavior:
As you can see the process resides in the windows folder related to .NET framework. The key thing to pay attention to is the process mutex activity.DarkKomet consistently creates a mutex with the syntaxDC_MUTEX-<7 Alphanumeric Characters>. In the instance above DC_MUTEX-0UJ9GZV is the mutex. The same mutex was created each time the process executed so in this case almost 500 times.
Once the RAT was running a single connection was established to a dynamic DNS based domain, briach202.no-ip.info, which resolved to an IP address of 220.127.116.11. At which point a connection was established on port 1126 as shown below:
Unfortunately, the server wasn’t responding so no activity was detected. It was at this point that Talos started pivoting around telemetry based on the IOCs associated with this sample and found that this threat actor had been performing these spam campaigns for quite some time. Based on the domain briach202.no-ip.info, Talos was able to identify samples dating back to early January 2015 that were delivering the DarkKomet RAT. What is interesting to note is that the threat actor has consistently been evolving and releasing new variations of the malware while still keeping the same dynamic DNS domain. This allowed Talos to track them regardless of IP address and determine how they have evolved. Talos was able to leverage Threat Grids searching capabilities to achieve some of this information gathering and pivoting. By pivoting on the domain being utilized, Talos was able to quickly review historical samples and find a large amount of samples correlating the potential origins.
Through the analysis of samples over time Talos noticed an evolution in the use of process names for this campaign. The first sample analyzed was found in early January 2015 and used the following process names:
\Documents and Settings\Administrator\Application Data\Microsoft\LookupSvi.exe
\Documents and Settings\Administrator\Application Data\Microsoft\secdrv.exe
The basic behavior was the same for all the samples Talos found, but the process names continued to evolve. Below is a list of the additional process names Talos has observed being utilized.
\Documents and Settings\Administrator\Application Data\Microsoft\Windows\AppMgnt.exe
\Documents and Settings\Administrator\Application Data\Microsoft\Windows\hknswc.exe
\Documents and Settings\Administrator\Application Data\Install\Host.exe
There were a couple other interesting techniques that Talos observed being done to try and establish persistence on the affected systems, one such was using scheduled tasks from the CLI to get the service started every time a user logged in. This helps ensure that the threat actor would receive a connection attempt from the system when a user was active.
In total Talos analyzed samples over a six month period, however the activity seems to have spiked in the last 30 days with more than 50% of samples occurring during that time period.
Across all the samples Talos observed all the functionality was the same; Establish remote access to the system at briach202.no-ip.info. The way that DarkKomet operates is the infected system becomes the server and beacons out to the malicious actors client, briach202.no-ip.info. In some cases the DNS lookups failed and no connection was established. On other occasions the host was actively resetting communications and in others just not actively listening. This could be due to infrastructure movement, maintenance or just bad uptime. Talos was able to observe successful connections on several occasions and communications were established with the threat actors malicious client. Below is a sample of the TCP stream of data that was being exchanged.
The communication is encoded with the majority of the traffic originating from the infected system. One commonality as well is the destination port. The infected system always connected to the remote system on port 1126.
Airway_Bill 23-06-2015 Index.zip
06-06-2015 Delivery Airway_Bill Index.zip
Airway_Bill 18-06-2015 Index.zip
Airway_Bill 23-06-2015 Ind#U202eslx.exe
Airway_Bill 23-06-2015 Ind#ecode.exe
06-06-2015 Delivery Airway_Bill Ind#U202eslx.exe
Airway_Bill 18-06-2015 Ind#U202eslx.exe
Threat actors are constantly attempting to deliver something to end users. This is just another example of a different type of tool that has been being delivered over the last six months. By not changing the command and control infrastructure the threat actor has made it easy to track them from one sample to the next. Even with the relative lack of ingenuity here, using a freeware Remote Access Trojan phoning back to the same host, the threat actor did use some clever mechanisms like multiple tiers of folders and RLO to evade basic detection engines and antivirus as well as trying to hide the processes by mimicking existing well known legitimate processes as well as potential sandbox evasion methods. These techniques have helped aid the miscreant to deliver the RAT to unsuspecting users for more than six months.
Threat actors are always going to try to get access to systems and a layered approach to security is always going to be the best protection. Threat actors commonly target one type of technology, in this case malicious file detection, but will rarely target multiple different types of technologies. This also reinforces the need at an organizational level to evaluate the usage of Dynamic DNS services. If there is not a legitimate business need to allow it, block it.