In a discussion with a customer's threat analysts earlier in the year we debated various different types of solutions’ abilities when it comes to detecting new and stealthy forms of communication with attackers’ command and control servers. The conversation inspired me to put DG to the test with a particularly sneaky piece of malware, and I thought the results from my demo were worth sharing.
Last year saw a renewed increase of malware campaigns using social media-based channels for command and control communications, like the Russian malware Hammertoss which uses Twitter. This is not a new phenomenon; this type of channel saw its first appearance circa 2009 and has been followed closely by security researchers ever since (including this excellent series of in-depth analysis articles from Lenny Zeltser on the subject).
Perhaps the most high profile case of attackers using hard-to-detect C&C channels of recent is the hacking attacks on the Democratic National Committee believed to have been carried out by Russian government-sponsored APT groups. The success of those attacks has been largely attributed to their use of well-engineered phishing emails to deliver the “XTunnel” malware, which uses SMTP and POP3 protocols (among others) to disguise C&C communications as benign email traffic via a feature Microsoft dubbed “STRONIUM” in an earlier edition of its Security Intelligence Report. Reading up on these attacks brought me back to my conversation with this customer on the subject of how to best see through C&C obfuscation techniques.
Of particular concern to this customer was the use of encrypted webmail services used as the command and control channel and more specifically the use of a web platform like Yahoo. This customer was referring to malware similar to a remote access tool (RAT) reported by Virus Bulletin in August 2014. Use of the Trojan, given the name IcoScript, dates as far back as 2012.
Detecting this type of communication is quite difficult as most network traffic will look like normal end user activity. As a result, organisations cannot rely on detection via traditional network intelligence; detection must instead be focused on the endpoint, where the malware runs.
Herein lies the challenge. The malware we focused on establishes its communications channel using Microsoft APIs for interprocess communications and the component object model (COM). COM provides a means for any application to control certain Windows applications; Internet Explorer specifically in our case. The customer felt that this malware is almost impossible to detect, so I decided to obtain a sample and see whether the Fortra DLP endpoint agent would be able to detect (and ultimately block) this activity. The malware sample used piggy backs on the user's browser session and creates a hidden browser process. The network communications then exfiltrate data via that session; the malware never directly communicates. This technique provides the malware a high level of obfuscation even from traditional endpoint protection solutions.
Where is the browser session?
First let's take a concrete look at how a sample of the malware uses Internet Explorer. This particular malware poses as Adobe Flash player to trick users into downloading and running it. The process A3DUtility.exe runs in the background until the user opens Internet Explorer. Once that happens, a new set of browser processes appears in the process tree running under the svchost environment. Here’s how this looks in Process Explorer:
The malware achieves this by issuing a call to the COM API which in turn calls the system DcomLauncher service. These browser processes are run via a COM call. The result is that we have an iexplore.exe process with a parent of "svchost.exe -k DcomLauncher" using the option -Embedded at the command line. We can confirm this by looking at the properties of the processes running:
So how would Fortra DLP fare?
Fairly well actually! As reminder, the Fortra DLP endpoint agent has a unique, low-level visibility into what is happening on the host machine. This can be leveraged to identify when certain process are launched in an unusual manner, for example as an embedded Internet Explorer in the DCOM environment.
Let's take a look at how DG captures those events. First DG alerts us that a recently downloaded executable has been launched by the user:
At first all this process does is to launch a batch script via a command line. The batch script in turn creates and launches a new executable and resets the original file's attributes so that it can manipulate it in the background if necessary:
The process then lays dormant. In this test, the next event only happens 15 minutes after the initial execution by the user. At that time DG detects an iexplore.exe process being launched via COM and flags it as "ATP3032-D-Hidden Launch of Internet Explorer via DCOM." From that point the agent begins to track all activity associated to the particular Internet Explorer process:
We then see it establishing communications with mail.yahoo.com and accessing the Yahoo portal as if it were any other user. However from the host’s point of view this is happening in the background and no visible evidence is seen. From the network perspective, we seeing just another connection by a user to a webmail service. However, given the context provided by the previous sequence of alerts, we can identify this seemingly innocuous traffic as suspicious:
Conclusion: Don't forget about the endpoint!
An ongoing theme being presented of late is that the endpoint can provide the most complete information to detect and thwart malware. This example shows once again that what may look normal for some detection systems can actually be more complex than a simple network flow between an endpoint and webmail service. By taking into account the chain of events and the context leading up to the outbound mail.yahoo.com traffic, we can determine with a reasonable degree of confidence that this activity is suspicious and apply protective measures to block communications and ultimately contain/remove the malware. As attackers continue to refine their methods to make attacks harder to detect using traditional solutions, security teams should look to the endpoint as a valuable source of the information needed to prevent these attacks from succeeding.
