Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2014 > January
2014

There have been many legacy feeds available in RSA LIVE that contained threat intelligence feeds of known “bad stuff” that were attributed to older malware campaigns and threats.   These threats are simply not seen very often anymore.

 

Many of those older feeds will be deprecated soon.  Look for official statements regarding this, along with full details soon.  We are working to raise the quality of our feed content by eliminating elements that do not produce quality intelligence and detection for our customers.  The goal of RSA FirstWatch is to create feeds that reflect today’s threats.

 

One of the feeds scheduled to be deprecated  was the Malicious Filenames Feed.  It contained things like 1.exe, 2.exe, etc, and a.exe, b.exe, etc. The entries were based on older Trojans including the Storm Worm, Zeus Beta Versions and some intelligence gathered from professional services engagements over the years.  And while we wholeheartedly agreed that the contents of the feed were old and needed to go, we were also confident that we could substitute that older content with real-world, live intelligence gathered from the RSA FirstWatch  malware database.

 

Below is a feed that we use internally to “normalize” the known malicious filenames for alerts and tracking, versus the known “expected” filenames that we should try to ignore.  We are providing this as an example of the real-world malware names that we encounter in our malware database.   Below are some screenshots of this feed in action.

 

776307763177632

 

Essentially, this will become the basis for the new Live Feed of RSA FirstWatch’s Known Malicious Filenames.  You will see that these certainly are NOT a-z.exe filenames.  Many are associated with specific malware families, which will be noted when possible in the threat description column.

 

We have automated the generation of filenames meta in our database to populate this feed.  Here is how our logic works:

FirstWatch has identified behaviors and malicious activity in our malware database, and we track those behaviors as alerts.  These alerts represent known intelligence that has been verified by FirstWatch threat analysts.  One example alert would be “Password Stealing IE5 Trojans.”  We identified a specific pattern to this Trojan family and monitor its activity on an ongoing basis.  What we are doing now is selecting each of our known intelligence types from the Alert Keys and looking up and adding the top filenames associated with that intelligence.   Additionally we are also filtering out known normal and expected traffic.  The results are analyzed and added to the new feed.  If those values exist in that feed going forward, they will be ignored in new reports, yielding new filenames to analyze.

 

In addition, we look at the top executables by filename that are downloaded from infected systems. Those filenames, if judged to produce very low false positives, are also added to the new feed.  One example of a false positive would be “setup.exe.”  We understand that there are many malware samples that use this filename, however, there is an equally large number of legitimate software that uses the filename as well.

 

If you can’t wait for the new version of this feed to be on LIVE, you can install the one attached, at your own unsupported risk.  Refer to our previous posts here and here on how to use SA’s Live menu to install this feed.  The feed would be non-ip, index column 1, callback to the filename meta, and tag column 2, 3 & 4 as feed.name, feed.category, and feed.description.  This is actually two feeds in one- identifying known malicious file and whitelist file.  You can use this feed and add your own content as well.

 

All feedback is welcome.  Good Luck and Happy Hunting!

 

UPDATE:  I have replaced the original attachment to this post with a newer version of this feed.

NOTE: This blog entry originally appeared on RSA's Speaking of Security blog: https://blogs.rsa.com/rsa-uncovers-new-pos-malware-operation-stealing-payment-card-personal-information/

 

 

By Yotam Gottesman, Senior Security Researcher, RSA FirstWatch team

In a recent investigation, RSA researchers uncovered the server infrastructure used in a global Point-of-Sale (PoS) malware operation responsible for the electronic theft of payment card and personal data from several dozen retailers, mostly based in the U.S. Infection activity has also been detected in 10 other countries including Russia, Canada and Australia. While the malware used in the operation is not new, RSA researchers discovered that, beginning October 25th, it had logged track 1 and 2 data of payment cards it had scraped from infected PoS systems.

RSA anti-fraud researchers have been in contact with victim companies at the center of this operation, sharing key forensics information gathered in this investigation.

As part of RSA’s investigation that uncovered this stolen payment card data, RSA observed “ChewBacca,” a relatively new, private Trojan used in this operation that features simple keylogging and memory-scraping functionality.

Untitled

Figure 1: ChewBacca server login page

ChewBacca Bot

ChewBacca features two distinct data-stealing mechanisms: a generic keylogger and a memory scanner designed to specifically target systems that process credit cards, such as Point-of-Sale (POS) systems. The memory scanner dumps a copy of a process’s memory and searches it using simple regular expressions for card magnetic stripe data. If a card number is found, it is extracted and logged by the server.

 

Untitled

Figure 2: Using RegEx to scan for credit card data in memory.

 

RSA observed that communication is handled through the TOR network, concealing the real IP address of the Command and Control (C&C) server(s), encrypting traffic, and avoiding network-level detection. The server address uses the pseudo-TLD “.onion” that is not resolvable outside of a TOR network and requires a TOR proxy app which is installed by the bot on the infected machine.

 

Installation Process

The Trojan is self-contained and runs as-is. It has no dynamic configuration and is non-modular according to RSA’s investigation.

Upon running, ChewBacca installs a copy of itself in the Windows Start > Startup folder, as a file named “spoolsv.exe“, for example:

Untitled

Figure 3: Dropped ChewBacca malware file.

The file name disguises the Trojan as a Windows Print Spooler service executable, and placing it in the Startup folder causes it to run automatically at Windows startup.

After installation, the keylogger creates a file called “system.log” inside the system %temp% folder, logging keyboard events and window focus changes.

Based on its current findings, RSA believes that deleting this file and rebooting will effectively remove ChewBacca from an infected system.

ChewBacca Server Side

The server side control panel allows the botmaster easy access to manage the botnet and review the compromised data. A “Reports” screen lists information about the compromised machines and the data captured from each of them. Data is presented in either parsed form or in raw text (as it was grabbed from the machine).

Before disappearing behind TOR, the controller of this botnet was observed logging into the server from an east European country.

Untitled

Figure 4: ChewBacca server-side reports screen.

 

The ChewBacca Trojan appears to be a simple piece of malware that, despite its lack of sophistication and defense mechanisms, succeeded in stealing payment card information from several dozen retailers around the world in a little more than two months.

Retailers have a few choices against these attackers. They can increase staffing levels and develop leading-edge capabilities to detect and stop attackers (comprehensive monitoring and incident response), or they can encrypt or tokenize data at the point of capture and ensure that it is not in plaintext view on their networks, thereby shifting the risk and burden of protection to the card issuers and their payment processors.

RSA researchers are continuing their analysis and monitoring of the operation.

 

Yotam Gottesman is a senior security researcher at RSA’s FirstWatch team. Yotam is an expert in software security and malware research, having specialized in protocol analysis and reverse engineering malicious code written for both the Windows and Linux OS. When not dissecting malware, Yotam can be found trading stocks and closely watching financial trends.

More and more malware focuses on Referral Abuse than ever before.  If you haven't seen our previous article on massive referral abuse, you can check it out here at RSA's Speaking of Security Blog. The reason referral malware is gaining in popularity is because it is a low-risk, high reward method of using a botnet to generate easy cash.  Instead of breaking international laws using a botnet to harvest credit card information, botnets are now being used to install software, click ads, and even host files, each of which pays up to several dollars per infected host by companies offering referral or partnership cash-per-install incentives.  Of course, in most cases, if not all, the companies offering referral cash have little or no idea that malware authors are automating the installation of this software and the siphoning of this referral cash.

 

Below is a screenshot (translated from Russian) of one such Russian referral program.  They offer 1,250 Rubles, which is about 37 US Dollars for every 1000 downloads from their site.  If you could get a botnet to automate the installation of software under a referral ID, this would be an easy way to generate some quick cash.

 

77044

Install Monster will actually host popular files on behalf of software authors, and it does this by hosting certain DNS names.  If someone wants a particular file, they have to go through Install Monster to get it.  This is what this traffic looks like in our Massive Malware Database for the past 24 hours:

 

77045

There were over 1000 unique samples of malware that produced this traffic.  And if each session represents a single file download, this translates into almost 200 dollars of referral cash.

 

One sample infector can be viewed here at VirusTotal.  You can see from the description that Dr.Web refers to this malware as the InstallMonster.47 Potentially Unwanted Program.  Here is another writeup of the same variant over at McAfee

 

Here is a sample session:

 

77052

There is a post to /api/index (with no extension) and the information exchange looks to be encrypted.  As it turns out, this specific activity is enough to accurately identify the Install Monster software on your network.

 

You could create a rule and call it InstallMonster Detected.  Alert it to your Alerts field, or Risk.Suspicious The contents would be:

directory='/api/' && filename=index

 

As referral malware gains in popularity, I expect to see blended threats coupling Zbot, Zeus, Citadel or others with Referral cash siphoning.  This MonsterInstall was delivered via the Symmi flavor of adware.  Next time it could be delivered by a more nefarious threat.  Use this easy rule to detect referral abuse, but be on the look out for deeper compromises on affected systems.

 

Good Luck and Happy Hunting!

Another great find.  As pointed out by Rui.A too!

The RSA Incident Response (RSA IR) team has developed an in-depth report called Emerging
Threat Profile: Shell_Crew
, where they detail the TTPs used by an adversary
that we have dubbed “Shell_Crew.” The Shell_Crew report is based on RSA IR’s
multiple incident response engagements involving a group of advanced threat
actors whose objective is to gain access, stay entrenched and ultimately steal
as much data and intellectual property as possible. 

 

It appears that Shell_Crew has persisted in enterprises of
varying sizes for years without being detected – updating or replacing existing
malicious backdoors and continuing to map the enterprise while installing Web
shells and poisoning existing web pages. These tenacious approaches make it
difficult for an under resourced internal security team to detect and remediate
the actions of this adversary.

 

The report is now live at http://www.emc.com/collateral/white-papers/h12756-wp-shell-crew.pdf,
and a blog detailing the threat is also now live on Speaking of Security
(https://blogs.rsa.com/dissecting-tactics-techniques-advanced-adversary/).

 

A few of the highlights include:

  • Prevalent use of Web shells to maintain low level
    persistence in spite of determined remediation efforts;
  • Altering or poisoning existing legitimate web pages
    maintained by an organization;
  • Occasional use of Web application framework exploits to
    achieve initial entry versus standard spearfishing attacks;
  • Lateral movement and compromise of Digital Code Signing
    Certificate infrastructure;
  • Abuse of Code Signing infrastructure to validly sign custom
    backdoor malware;
  • Exploiting systems using different SETHC.exe methods
    accessible via Remote Desktop Protocol (RDP);
  • Long history of IP/DNS telemetry allowing for historical
    research and link analysis;
  • Placement of malicious proxy tools introduced into the
    environment on Windows server based proxies to bypass proxy logging;
  • Extensive use of time/date stomping of malicious files to
    hinder forensic analysis; and
  • Malware leveraging compromised credentials to bypass
    authentication NTLM proxies (proxy aware).

                

Check out the full report.  Feel free to add thoughts and comments!

At the bottom of this post will be the CSV file that RSA FirstWatch uses to identify known ZBot activity within our Massive Malware Database.  Each IP address identified to be participating in ZBot beaconing gets added to the FirstWatch C2 IP Feeds, which is available via Live.  But this feed breaks out the IP addresses into distinct variant types.  It should also be noted that many IP addresses will repeat within this feed, however, these IPs have been spotted participating in multiple ZBot campaigns, sometimes simultaneously.

 

ZBOT BACKGROUND

It helps to understand how we detect ZBot in our environment, where we have thousands of virtualized machines chewing on different malware samples.  ZBot almost always shows up on a network as an unknown protocol communicating via UDP to an unusual high port.  We have automated reports that will hunt these down for us so we can include them in our feeds.

 

That said, we don't want to identify anything that we have already identified in the past.  New and unknown is the name of the game for FirstWatch.  Repeated analysis of the same malicious IP addresses would be time consuming.  We really only look at traffic that is not already identified by either ourselves or one of our Threat Source partners.

 

Our Rule

FirstWatch uses a capture rule and Reporter rule to identify this traffic in an automated fashion.  It needs to be noted here that our rule will not work in your environment unless you have already normalized all of the other service type 0 traffic on your enterprise.  The rule is shown here to demonstrate our methodology.

 

The real crux of our hunting rule is to look for:

alert !exists && threat.desc !exists && service=0 && org.dst exists && udp.dstport exists

 

This means we are looking for traffic where we don't already have a predefined alert.  Since all threat sources write meta to the threat.description key, and we are only looking for new and unknown traffic, we eliminate that as well.  We know we are looking at unknown protocols, so service type 0 is needed.  We look for the existence of a destination organization to focus on outbound traffic to a UDP destination port.

 

What we get are several instances of malware runs that beacon to the same IP address on the same UDP Highport.  This was from Friday's report:

 

76742

We notice that several internally infected hosts attempted to contact 213.203.175.12 via UDP port 3159.  A simple search of VirusTotal produced this sample with similar behavior.  From the bottom of the behavior tab, we see we have a match:

 

76746

So chances are very likely that this traffic is ZBot related.  Each IP address listed above gets added to our known C2 IP feeds. With no real agreement among AV vendors as to which flavor ZBot this might be, the FirstWatch team would typically resort to naming this threat generically along with a date stamp of when it was seen.  For instance, I would call this one "Zbot 01152014."

 

And we would add that meta to the internal feed we use to identify known variants, whcih is what we are going to share with you now. 

 

As you review the feed below, keep our naming conventions in mind when wondering how we came up with the name of the ZBot variant.  Most are mapped back to Sophos, which seems the best at incrementing ZBot version types.  Others are simply labeled with initials and a date stamp.  But each IP address is known malicious.

 

If you implement this feed, keep in mind that it should not be a false positive if the service type is Zero via a UDP port.  Go ahead and download the CSV attached below, and follow the screenshots below to upload this feed to your SA instance.  As stated in our post about malicious User-Agent strings, it helps if you are indexing values on your feed meta keys.

 

First go to Live and Select Feeds.  You want to create a new AdHoc feed.  Name it Zbot Beaconing via Service Zero or something similar.  Browse to find your local CSV that you downloaded from this post.  If you ever want to add to this feed on your own, you simply download the file from the decoder via the download link.  Click Next.

 

76747

Now you pick which decoders will house your feeds.  Then click next.

 

76748

This is where the real configuration of the feed happens.  Match yours to the one pictured.  It is IP based, indexing field 1, where the values reside.  The other three columns are feed.name, feed.category and feed.description.

 

76853

Then click next to review, and finally click finish.  The feed will push to the decoders, and will begin to populate the feed key if you have any internal infections.

 

In our malware environment, it looks like this:

 

76860

And if it looks like this in your environment, I feel sorry for your Incident Response Team.

 

Feedback as always is welcome!  Good luck and Happy Hunting!

The Slugin Backdoor Trojan is a veteran piece of malware that has been around for about three years or more.  Once a host is infected by the malware, it will reach out to a webserver and notify the cyber criminal that an infected host is alive on the internet, along with other local machine information.  This is what the notification traffic looks like:

 

76330

Do you see the query string that follows the question mark in the get request?  That is base64 encoded traffic.  This is what it looks like decoded:

 

ab0c2945-f56e-4976-812b-7d27ee8efcb3|az|2.1.12|5.1.3|COMPUTER-2QIWNS|user|1

 

As you can see, there is a unique identifier followed by version information, the computer name and information about the current logged in user.

 

The original sample of the infector file can be located here at VirusTotal.  As you can see there is wide agreement that this malware is "Slugin.A"

 

On a network, an infected host simply tries to checkin to the control server once.  This is what it looks like in SecurityAnalytics:

 

76331
76335

This is enough meta to explore whether or not this threat follows a predictable pattern.  I created a custom drill looking across our entire malware database for:

action=get && filename='process.php' && directory='/api' && query begins 'xy='

 

This is the result I saw:

 

76336

The behavior is indeed consistent across multiple Command Hosts.  But rather than using the complex drill above, it turns out that a simpler approach is to simply create a rule for the user-agent string of "pcicompliant/3.33"

 

It should be remarked that malware that masquerades as PCI Compliant traffic seems like an insidiously clever idea.  However, with Security Analytics, it makes that traffic stick out like a sore thumb, which is what brought it to my attention in the first place.

 

All hosts shown above have been added to the FirstWatch C2 Domains list, and the malicious user-agent string should be added as a standalone rule or appended to the Malicious UA Strings feed previously posted here.

 

The rule would be called Slugin Trojan Traffic Detected and its contents would be:

client='pcicompliant/3.33'

 

Good luck and happy hunting.  A pcap is attached for demonstration and testing purposes.

I named this new botnet type the "TSONE Dorkbot" because the executables downloaded via this botnet have a very low detection rate on VirusTotal, but Fortinet consistently flags the malware as "Dorkbot."  It gets the "TSONE" moniker because the c&c communications each happens from the "/tsone/" directory as shown below.  This botnet may very well be spread via email spam, however each malicious EXE is coupled with a photograph that matches the EXE filename.  For instance, the IAMLOLJPG.exe features elephants doing "funny" things.

 

That said, let's begin with how this botnet was encountered.  FirstWatch has a report that automatically identifies zero days. This is what I saw-  note the highlighted pattern showing multiple direct-to-IP connections looking for dat files in the "/tsone/" directories.

tsone-query.JPG.jpg

Clicking into the report, I was able to see what the dat file request looked like:

 

tsone-datcontent.JPG.jpg

The highlighted portion above certainly looks like command and control encrypted communications.  Next, I drilled into the destination IP to see what else has happened with this website.

 

php-put-exe.JPG.jpg

You can see from above that multiple IP addresses in our sandbox encountered this malware.  There were also 15 puts to a PHP extension where the filetype is a windows executable.  This allows us to create a detection rule to see where these similar conditions have occurred in the past and to flag this activity going forward by creating a decoder capture rule.  Mine looks like this:

service=80 && action=put && extension=php && filetype=windows_executable

 

You can now also see the filenames associated with the HTML Puts of the filename ajuno.php.  The younaked, iamnice, iamfunny, etc, are each named with an enticing name.  Interestingly, the same single ajuno.php file will deliver a different version of dorkbot.  Here is what the EXE session looks like:

 

tsone-response.JPG.jpg

The u=name paramaters likely selects which variant of dorkbot gets downloaded.  I extracted all of the files delivered:

 

extracted-files.JPG.jpg

The three file extractions at the bottom appeared to be corrupt, and the four at the top are actually just two dorkbot variants.  The VirusTotal reports are located here and here.  Each have very low detection rates and were first spotted in the past 24 hours.

 

Each IP address I've encountered by using this rule has been added to the FirstWatch feeds as a malware download domain or IP address, so customers are armored against this threat.  But be sure to run this custom query against your collection, and if there are very few false positives, create an alert with the rule.

service=80 && action=put && extension=php && filetype=windows_executable

 

Good Luck and Happy Hunting!

Koobface is an older worm that relies on Facebook likes to spread.  It takes advantage of compromised webservers to host malicious scripts.  In most instances, Koobface gets downloaded from a webserver from a "/.sys/" subdirectory.  But other variants utilize a randomized directory structure on the compromised server to retrieve the malware.   Normally, this would make it a bit of a challenge to detect, but there seems to be two common hard-coded User-Agent strings that should be easy to detect in an Enterprise.


We noticed a recent variant (Jan 2, 2014) in our sandbox that is clearly detected ashttps://www.virustotal.com/en/file/9c0c55bb2517629524b42b22ce5c7bf878a97a4996ffb45bf9fed9f4f1cdfdcf/analysis/Koobface at VirusTotal here.

 

First, lets see what a bunch of Koobface infections look like in SecurityAnalytics:

 

75514

As you can see, most connections are a put to the /.sys/ directory with no filename.  Those would be pretty easy to detect with a custom rule, but what about all of the dynamically generated directories?  You could use a Regular Expression rule but even that structure is not regular enough to easily detect the traffic.

 

There are specific query strings that follow a pattern as well.  They typically look like this:

 

75515

You can see that they all begin with the phrase "action="

 

So a rule to detect most of this traffic would be:

directory='/.sys/' && query begins 'action='

 

And while that would detect 95% of the traffic, what about the remainder?

 

As it turns out, there are two very distinct User-Agent strings observed to be engaging in Koobface beaconing.  The first is a Russian Language encoded browser running a 2005 build of Firefox.  The "ru;" in the string denotes the russian language.  That string is:

mozilla/5.01 (windows; u; windows nt 5.2; ru; rv:1.9.0.1) gecko/20050104 firefox/3.0.2

 

The second one is even odder.  It is a User-Agent string that is tied to the Nauru language.  Naulu is a tiny island in Micronesia with less that 20,000 residents.  Chances are that no one should ever encounter a browser encoded in this language.  That UAstring is:

mozilla/4.0 (compatible; msie 7.0; na; )

 

So the best way to detect Koobface, based on my observations, is to use a combination rule that would be:

directory='/.sys/' && query begins 'action=' || client='mozilla/5.01 (windows; u; windows nt 5.2; ru; rv:1.9.0.1) gecko/20050104 firefox/3.0.2','mozilla/4.0 (compatible; msie 7.0; na; )'

 

Set the rule to alert in your alert field, risk.warning or your own custom alert key.

 

Good luck and Happy Hunting!

The "njRAT" Remote Access Trojan is a popular password stealing remote control applet used mostly by threat actors in the Middle East.  However, this trojan kit is widely available for download, and its ease of use has made this trojan pretty popular.  The FirstWatch team has developed a lightweight detection for this with a very simple rule. 

 

First, this is what the payload of njRAT looks like:

 

75421

The connections always begin with an "lv" and the next string shows that the victim host has been enumerated of its unique identifier, logged in user, Operating System and more.  The next system involves a screen capture of the local desktop.

 

Since this traffic is usually on the default TCP destination port of 1177, and the service type shows up as UNKNOWN or Service Type 0, a very simple rule would be:

service=0 && tcp.dstport=1177

 

However, many of the destinations that these trojans are intended to communicate with look to have been shut down, and while the endpoint is trojanized, it is unable to connect to its parent server, resulting in just syn connection attempts.  Advanced users may want to look for only established communications with payload.  So adding "&& payload exists" may make the detection more effective.

 

Here is the current view of the Middle Eastern participants enjoying njRAT access from our sandbox:

 

75422

Feedback as always is appreciated, and Happy Hunting!

Filter Blog

By date: By tag: