Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2013 > April
2013

Pastebin is a popular copy and paste site- used by developers for code sharing, and by data exfiltrators for offsite storage of sensitive information, and even by hacker groups to publish their various manifestos.  For several weeks I've had an Informer report running against our sandbox looking for any access by known malware into Pastebin.  I got several hits over the weekend.  And while pastebin is supposed to only house plain text copy-pastes, there is a way to encode an executable in Base64 and post it onto the site as text.  As you will see below, some malware downloaded two password stealing tools via plain text, decoded it, and installed it on our sandbox machines.

 

I was first alerted to the activity via an Informer Report.  If for some reason your enterprise is not blocking access to Pastebin, you might find this report useful in your Security Analytics Deployment.  It is attached below.  This report also looks for user-agent strings, and "autoit" is highlighted.  In most of the events in this report, a UA string is noticeably absent.

 

58053

So working from the top of the report down, there were 68 sessions going to this site:

http://pastebin.com/raw.php?i=c6axjjzj

And the results are base64 encoded.  It looks like:

ZHJpemVyLm5vLWlwLm9yZw==

 

There is a handy base64 decoder online here.  Pasting this code into that site reveals a domain name, likely used for secondary malware delivery:

drizer.no-ip.org

 

So you can see that decoding Base64 results can be pretty easy.  Now onto the executables in the second result in the report above.  The requested link was:

http://pastebin.com/raw.php?i=Xr6hkp4Z

 

And the base64 output is simply too long to go here.  I decoded it and downloaded the binary file, renamed it to an EXE, and the application file took on an icon that looked like this:

58054

Now using CEFF Explorer I could look into some of the details of this application:

58055

 

So this software is intended to swipe the stored passwords in browsers.  Another file link shown above also will reveal Base64 encoded tool to retrieve passwords from your email file store.

 

Bottom line is block access to pastebin, as there is no valid Enterprise use of the site that wouldn't introduce significant risk.  If you can't block it, keep an eye on what is being downloaded and requested, and if its base64 encoded, now you know how to decode it and investigate it.

 

Happy Hunting!

-Fielder

I found something pretty unusual in our sandbox today.  It appeared to be a dead ringer for Zeus-style C&C communications, but the webserver, hosted in Russia, was climing to be www.google.com.  This is what it looked like in Security Analytics:

 

57700

57701

57720

And when I drilled into it, this is the Zeus-style query and response:

57721

I looked up the IP address and it has been associated with malware in the past.  But this is the first instance I can recall of a host that is masquerading as someone else to avoid detection.  Remember, the alias.host meta key is only populated by what the destination server claims that it is.  SA does not do any independent DNS lookups on the IP destinations. 

 

The destination IP has been added to our RSA FirstWatch C2 IP feeds available for deployment via Live.

RSA FirstWatch monitors Sandbox Clusters to identify malware trends to develop detection capabilities for its Enterprise Customers.  With new detection capabilities, this space will be used to explain threats and how to detect them.

 

I was investigating a non-related issue via the Urlquery.Net portal when I spotted an unusual trend-  several urls each called for a filename called "logos.gif" followed by a 12 character hex and numeric query.  A screenshot of it is below:

 

57229

Further research describes this activity as the Sality Worm, or as Sophos calls it, the KooKoo worm.  You can see writeups here and here.

 

So I began to wonder if we had seen similar activity in our own malware sandbox.  I created a custom query:

filename=logos.gif && query length 12 && query contains '='

 

And I went back in our timeline and there were certainly some hits.  And I also noticed that there was a common malicious user-agent string associated with this activity which is also handy to detect the Sality-KuKu worm.  The second rule to detect this activity would mere be:

client contains 'kuku '

 

57230

57234

Attached to this post is a NetWitness Rule File that can be imported into Security Analytics.  Happy Hunting!

Twitter is abuzz today about the recent Apache worm that causes servers to participate in a new threat called "Darkleech."  Apache servers seem to have vulnerable modules that allow attackers to inject iframes into the browsers of certain web visitors delivering exploit code.  ArsTechnica broke the story here

 

57057

 

The story is very helpful in pointing out exactly what the meta would look like if one of your enterprise users encountered the Darkleech string. 

The injected HTML iframe tag is usually constructed as IP address/hex/q.php. Sites that deliver such iframes that aren't visible within the HTML source are likely compromised by Darkleech. Special "regular expression" searches such as this one helped Landesman ferret out reported iframes used in these attacks. Note that while the iframe reference is formed as IP/hex/q.php, the malware delivery is formed as IP/hex/hex/q.php.

To clarify, the directory is not "hex" but a long hexadecimal string that changes.  This is still not a big problem to detect.  We have already published rules to Live that identifies suspiciously long directories and filenames.  But the key piece of meta here is the direct to IP get request.  We have a risk.suspicious meta alert for just such an event.

 

The story also links to Urlquery.net and provides a long list of likely compromised sites.  The most helpful part is the urls produced.  Here's a sample:

hxxp://195.189.114.10/ae1b9cc49ddca4ebe9ee068e06739c7d/ae1b9cc49ddca4ebe9ee068e06739c7d/q.php?omwsi=31:1l:1f:2v:1k

The get request shows a direct to IP connection, followed by two hex-string directories, followed by the filename of q.php with a query appended after the question mark.  So a rule to detect this in Security Analytics would be:

 

risk.suspicious = 'direct to ip http request' && filename = 'q.php' && query exists

 

Name the rule Darkleech Detected and push it to your decoders.

 

The same rule can be used as a custom query to look backwards in time to see if anyone has visited a Darkleech site in the past.  As  reminder, do the custom drill on the past three hours first, and then change the timeframe to all data.

 

Thanks and Happy Hunting!

-Fielder of RSA FirstWatch

Filter Blog

By date: By tag: