Tool Talk: Cracking the Code on XtremeRAT

Late last week, reports began to surface that the Israeli police (along with other regional law enforcement) were targeted by a malware attack.  The entry vector was described as a phishing campaign sent from Benny Gantz (head of the Israeli Defense Forces).  Initially, details and indicators around the malware were beyond sparse. Aside from the FROM: address, little was known that could assist in any sort of investigation. After nearly 24 hours from the first reports, both details and samples of the malware started to flow. As soon as we could confirm details of the phish email and the malicious attachments, we were able to cross-reference sample data already in our malware database and connect the dots.

Generic Dropper.p (Xtrat)

Generic Dropper.p (XtremeRAT)
























This is where, from the research side, things begin to get fun.

Automated malware analysis is nothing new to our industry. Most vendors (ourselves included) have tools to handle this internally, and assist our skilled human analysts with proper classification, documentation, and other recurring tasks that must occur with the daily barrage of new and unique malicious binaries. The bar for this threat, however, has been raised. With ValidEdge, we were able to generate enormous amounts of usable and actionable data from the execution of malware samples. We get feedback from basic static analysis, as well as from runtime data. We get all the usual system modification data, and full and complete network/communication data, and samples and memory dumps from second-level threats (dropped, created, downloaded entities). And it’s all done in a safe environment, with extremely robust reporting.

To fully illustrate, let’s focus on the Trojan that affected the Israeli police. In the McAfee universe, we detect this threat as Generic Dropper.p.

To start with, you simply submit your sample(s) to the ValidEdge appliance/host. The ways to do that vary depending on implementation. In my setup, it’s as simple as dropping the file, via FTP, on the appliance, then picking up the results set the same way (different directory on the FTP server). Easy and fast. I immediately had a set of results from my submission of the following sample:

Sample Data





The result sets are organized as a specific directory structure.

Analysis Report sample

Analysis report sample

This is where we typically end with most tools. The exception here, from my experience, is that there is much more data generated by the appliance to start taking action on.  The way in which the information is organized is also very friendly and workable. Some basic examples follow:

Sample Data

Sample Data

Sample Data 2

Sample Data 2

Sample Data 3

Sample Data 3

Sample Data 4

Sample Data 4

From here we can get enough static data to build a picture of the malware and its behavior. We also have network data and full memory dumps and screenshots at our disposal should we need to dig further.


Memory dumps



All the secondary/dropped files are presented as well. As such, these can be easily analyzed in context.

Dropped Files

Dropped files

Dropped files, specific to this threat, are detected via McAfee Global Threat Intelligence along with the current DATs.


Name: word.exe
MD5: 2BFE41D7FDB6F4C1E38DB4A5C3EB1211
Detection: Artemis!2BFE41D7FDB6

At this point you have plenty of information to understand what this threat is doing, how it communicates, and much more. Some would argue that deep malware analysis is an art form. But to embark on that sort of journey you need enough data to make constructive, creative, and accurate decisions. Tools like ValidEdge do exactly that.

If you would like to learn more, you can read the following sources:


























Latest Yahoo Data Breach Restates Need for Basic Security

News broke today of a large data breach against Yahoo Voices, resulting in more than 400,000 username/password combinations being posted in clear text. The compromise involved a basic SQL-injection attack against an exposed Yahoo server (  Similar to other recent events, the account data was reportedly stored in an unencrypted state.

We see this type of attack over and over. Most recently LinkedIn and eHarmony were in the news with similar issues. This Yahoo breach is just the latest in a series of similar attacks that occur in multiples every day.

The attack was launched by the D33DS Co., whose release included this:

“We hope that the parties responsible for managing the security of this subdomain will take this as a wake-up call, and not as a threat. There have been many security holes exploited in webservers belonging to Yahoo! Inc. that have caused far greater damage than our disclosure.”

D33DS is probably correct in that latter sentence. But are their methods and motivation ethical or legal? That’s a different story. Regardless, Yahoo’s overlooking basic countermeasures against basic attacks (such as SQL injection) cannot be excused.

This is not the first time that Yahoo has been compromised in this way. During the last five years, Yahoo Local Neighbors, Yahoo Kids, Yahoo Classifieds, and others have been successfully targeted.
Ironically, there is a blog on SQL-injection prevention on Yahoo Voices. It was posted in 2009.

What else is interesting about the latest breach?

More than just usernames and accounts were exposed. If there was ever a time to heed warnings about password reuse, especially across public and high-traffic social systems, this is it. Yahoo may have been the focus of this attack, but data in the dump could be used to target specific users from AOL, Microsoft, Google, Comcast, SBC Global, and others.

Here is a breakdown of associated domains that appear in the D33Ds release:


Yahoo! Breech top 20 domains

Yahoo breach Top 20 domains

I’ll leave you with several McAfee resources for understanding SQL injection:


RDP+RCE=Bad News (MS12-020)

See March 15 and 16 updates at the end of this blog.



The March Security Bulletin release from Microsoft was relatively light in volume. Out of the six bulletins released, only one was rated as Critical.

And for good reason. MS12-020 includes CVE-2012-0002. This flaw is specific to the Remote Desktop Protocol (RDP) present on most current versions of Microsoft Windows. The RDP service, by default, listens on TCP port 3389. And because it’s so darn convenient, lots of people like to open their firewalls/ingress points to the traffic.

This is a bad/dangerous/insecure thing. (Choose your own favorite term.) I hope this issue (and many others before it) will influence anyone’s decision-making process when it comes to network hardening, external access, etc.

This is certainly not the first flaw in RDP. It is quite significant in that it does not require authentication to exploit the flaw–just a firing of some specially crafted packets. From that point the world (or the world that the compromised host lives in) is the attacker’s oyster. This is especially bad because the RDP service runs in kernel mode, under the System account (in most cases).

Keep in mind that it is very easy and takes little time to find targets. You see this type of situation all too often:

port scan

It's Open!














This situation very quick leads to an intruder’s trying to login via brute force, or trying something new (like the flaw described in MS12-020) !

It's Alive!  RDP test

It Actually Works!!!!!












So, what can you do to protect your environment?

McAfee, Microsoft, and others firmly recommend that you prioritize the deployment of the MS12-020 update.

Other steps:

  • RDP is typically disabled by default. If there is any doubt, investigate and confirm in your environment whether and where it running.
  • In Windows Vista or later, enable Network Level Authentication (NLM)
  • Even if you have NLM enabled, the flaw can be exploited if the attacker can gain authentication. This means you should verify strong (nondefault, sufficiently complex) user/password combinations.


McAfee Coverage Data

Coverage exists in:

  • McAfee Vulnerability Manager (FSL release): 3/13
  • McAfee Network Security Platform (Sig release): 3/13
  • McAfee Remediation Manager (V-Flash): 3/13
  • McAfee DATs (partial coverage, for known PoC code, is provided as “Exploit-CVE2012-0002″ in the 6652 DATs): 3/17



——————- UPDATES ———————————


March 15: McAfee Labs has observed in-the-wild proof-of-concept code targeting this vulnerability. There are a few varied samples that we are both monitoring and analyzing. At this time the coverage/mitigation data already in this post is still valid.

We are continuing to monitor this situation and will provide updates as needed. An updated MTIS Security Advisory has been sent to subscribers.

To stay up to date on these and other critical security events, please subscribe to our McAfee Threat Intelligence Alerts.


March 16: The last 24 hours have been a virtual flood of proof of concept (PoC) and exploit details. Some of these are reliable; some are not.

  • This flaw was actually discovered by Luigi Auriemma in May 2011
  • There are numerous fake code examples and scripts on Pastebin and similar sites. As is typical, links to these fakes are advertised all over Twitter, etc.
  • The code examples/PoCs that are valid can successfully crash the RDP service, but do not move beyond that (to code execution or to allow for the possibility of code execution)


Urchins, LizaMoons, Tigers, and Bears

In early April, I wrote about the famed “LizaMoon” SQL-injection attacks. I said it then, and I’ll say it again now: SQL-injection (SQLi) attacks are a constant. Some of these attacks are more visible than others.  Some adversaries find intelligent ways to hide their tracks so as not to splatter evidence of their misdeeds all over various search engine results and caches.

There have been a number of reports and studies on the SQLi threat and the extent to which various regions/platforms/verticals/etc. are exposed. The basic takeaway runs along these lines:

  • On any given day, it is normal to expect to see around 1,600 SQLi attacks against the most attractive servers (Microsoft IIS/ASP.NET and Apache, for example)
  • The most prevalent and attractive (to the attackers) servers or platforms could easily expect to log 40 to 80 SQLi attempts per hour


Those are the current stats. Does this mean we should not be worried about the Urchin.js attacks? Goodness, no. But, my answer would be the same for the other 1,599 attacks going on every day.

As I highlighted in my previous LizaMoon blog:

Before any of us blow our IT budgets on database security goodies, we must all take the basic first steps. Simple and core techniques, such as constraining user input, validating user input, limiting types of input, encrypting sensitive data, and designing accounts with the principle of least privilege will go a long, long way.

The same basic principle holds true for this event.

On a side note, a few other handy stats may help put this into perspective.

  • According to Netcraft and a few others, there are around 505,000,000 sites on the web
  • Apache is the most popular web server platform, running around 327,000,000 sites
  • Microsoft (IIS/ASP.NET) is the second-most popular server platform, running around 79,000,000 sites


The SQLi attacks associated with the urchin.js script inclusion are specific to ASP.NET servers. Current stats indicate that the number of injected/affected hosts is just over 1,000,000.

This particular attack really began to take root at the beginning of this month.

Once the news broke, it was quite easy (via simple Google queries) to see evidence of the injections on affected sites.

Example Search Engine Results

Searchin' for Urchin

Technical Meat and Potatoes?

The injected script (urchin.js) forces the browser session to direct traffic to a number of malicious domains. At this point we have observed a variety of secondary malware. They range from the most basic generic Trojan families, to DNS changers, and now to rogue video codecs (bogus Adobe Flash Player, for example), which are backdoor Trojans.

The latest variants (example: MD5: fb4c93935346d2d8605598535528506e) are no different. This sample in particular is a rogue Flash Player install.

This Trojan contacts an number of remote hosts that are known to be “sketchy” and have been associated for years with other malware campaigns. (Remote hosts are registered under GigeNET.)

The LizaMoon Relationship

The original attack domains are:



Both of these share the same domain registration details as the original LizaMoon attacks.

Domain name: 

Registrant Contact:


James Northone
jamesnorthone @ hotmailbox .com

+1.5168222749 fax: +1.5168222749

128 Lynn Court

Plainview NY 11803


Again, both the original attack domains are registered under BIZCN.COM, which has a less than stellar reputation of associations (direct or otherwise) with malicious domains. This reputation can be traced back for several years.

Make Me Feel Safe–Again

I hope this information has put the threats in perspective. Don’t get me wrong; this attack is certainly visible, and deserves the attention of those who are exposed. I would like to stress (as we have done before) that this attack is one of many that occur constantly. Establishing a strong security posture and embracing the most basic and essential steps in web and database security will go a long way. You’ll find yourself much less exposed to Urchin.js as well as to the thousands of other SQLi attacks that are targeting your environments.

As of this writing, here’s your McAfee-specific coverage information:

McAfee AV/MWG Associated malware threats are covered under Generic.dx (varies),, and Generic Backdoor!dsm. This coverage also applies to the McAfee Web Gateway.
GTI-Enabled Coverage Coverage for associated domains/IPs is provided in deployments running the GTI component (example: McAfee Firewall Enterprise, McAfee Network Security Platform, McAfee Web Gateway, and more).


We will continue to update our content/coverage/countermeasures, as the situation requires.