Tuesday, May 15, 2012

ELSA: The Security Blog Companion

A healthy reading list is critical for any IT security professional.  In addition to a myriad of blogs I subscribe to, I also keep a close eye on my Twitter feed for the many links published there.  A tweet from Claudio pointed out the new Shadowserver.org post which contained a stellar description of dissecting an APT attack.  As I do with any technical post, while reading, I am unconsciously looking for indicators of compromise to dump into ELSA to see if our org has been affected as well.  Not only does it make reading technical posts more fun by "playing along at home," it's a great way to do some hunting.

So, in that spirit, if you want to play along with your own ELSA instance and read the shadowserver.org post, you'd just keep gedit or notepad open and paste terms in every so often.  The above post makes it especially easy by bolding IoC's.  What you end up with is something like this list of indicators:

Edit: I had to add spaces because Websense keeps flagging this site as malicious.

159.54.62 .92
71.6.131 .8
86.122.14 .140
glogin.ddns .us
222.239.73 .36
www.audioelectronic .com
213.33.76 .135
windows.ddns .us
222.122.68 .8
194.183.224 .73
ids.ns01 .us
javaup.updates.dns05 .com
194.183.224 .73
BrightBalls .swf
nxianguo1985@163.com .fr
www.support-office-microsoft .com

Now the fun part:  Copy and paste that whole list into the ELSA search field and hit submit.  It's as easy as that.  Since this was a targeted attack, there probably wasn't a hit for your org.  Don't feel too left out yet, though!  There's more hunting to be done.  One of the design goals for ELSA was to make it as easy as possible to take a starting point and fuzz the search to find related things.  In this case, you can start looking for domains from hostnames, so you can tack on these terms:

ddns .us
audioelectronic .com
dns05 .com
163.com .fr
support-office-microsoft .com

If you're using the httpry_logger.pl script that ships with ELSA or you've got Bro DNS logs being sent to ELSA, you could get some hits there.  Still no hits?  Let's dig even further.  If you're a member of ISC's DNSDB, you can do some passive DNS checks to see what else those malicious IP's have resolved to (or use the ELSA plugin for DNSDB).  For instance, windows.ddns .us resolved to 59.120.140 .77 on May 9th for some DNSDB member.  You can add that to the search list.  Then, by asking what other domains 59.120.140 .77 has resolved to in the past, you get:

updatedns.ns01 .us 
updates.ns02 .us 
updatedns.ns02 .us 
iat.updates.25u .com 
ictorgil2.updates.25u .com 
win.dnset .com 
xiunvba .com 
update.freeddns .com 
proxy.ddns .info

So you can tack all of these on as well.  If you still haven't gotten any hits, this wasn't all for nothing.  Click the "Results..." button and set an alert to fire on future occurrences of this hit, and now you'll be alerted if ever your org was attacked using any of this infrastructure.  Since these indicators are likely to become irrelevant soon, you can stick with the default end-date of a week, or extend it if you like.

By constantly dumping search terms into ELSA as you read, you can start finding some really interesting events that might have otherwise been missed.  That's why I encourage those of you who have an ELSA instance (if you don't, take a half hour and install it!) to keep it handy as you progress through your daily feeds.

Wednesday, May 9, 2012

Multitenancy Botnets Thwart Threat Analysis

There was a great thread on the EmergingThreats.net mailing list today regarding writing IDS signatures for a recent botnet communications channel.  This a very typical topic for discussion on the list, but in researching possible signatures, I found some surprisingly easy to observe communication of a compromised asset with is controller which shows how difficult it is to parameterize the threat of a given botnet.  Even labeling a botnet has grown extremely difficult as the codebases for each botnet are so intertwined that the tell-tale characteristics of each one blend until there's little distinction between them.  This makes attribution of attacks very difficult and provides a fair amount of anonymity through abstraction to the botnet masters.

As the exploit and agent codebases converge, the best parts of each are being used which is allowing small-time, novice crooks all the advantages of the highly effective hacking and command-and-control frameworks that used to be available only to the best criminals.  The increasingly assimilated code also allows researchers fewer opportunities for attribution via inference.

A positive on the defender's side of this arms race is that the converged code means that fewer IDS signatures need to be written, though the increasing surreptitiousness of the command frameworks continues to make this a constant challenge.

As the code converges, so does the consumers of the services the bot agents provide.  A recent article by Brian Krebs looked at the convergence between cyber criminals and cyber spies.  What I observed today certainly supports a corollary to that theory in which cyber criminals sell services to hacktivists.

During routine incident response, we discovered a compromised workstation which tripped the "ET TROJAN W32/Jorik DDOS Instructions From CnC Server" IDS signature.  When we pulled the traffic up using StreamDB, we were presented with the clear-text HTTP communications between the bot and its master.  The messaging looked almost identical to that of the Anubis report pcap referred to on the mailing list:

POST /sedo.php HTTP/1.0
Host: windowsupdate.dodololo.com
Keep-Alive: 300
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 49

id=pc5_916a4f72ffa89a4e&s5_uidx=1337&os=2600&s5=0HTTP/1.1 200 OK
Server: nginx/1.2.0
Date: Tue, 08 May 2012 21:40:51 GMT
Content-Type: text/plain
Connection: close
X-Powered-By: PHP/5.3.12


This is an HTTP POST from the infected Anubis sandbox client to the botnet controller located in the SYS4NET virtual private server host in Alcantarilla, Spain.  The client reports its name and proxy information and is given commands, which in this case, are to download two executables and run them, then start a denial of service attack on (www.christian-dogma.com).  The bot then proceeded to send 10 HTTP requests per second to that site for 100 seconds.

On our network, our infected machine received slightly different commands:


It downloaded a similar executable, but its denial of service attack was 10 SYN packets per second for 120 seconds against (viewpointegypt.com).

What is interesting is that both of these sites are related to Egyptian politics, and if I'm reading the translated page correctly, christian-dogma.com caters to Coptic Christians in Egypt.  Egypt is still in some turmoil during elections after last year's Arab Spring, and so it makes sense that hacktivists would attack rival political groups and sites affiliated with demographics belonging to those political groups.

So, this botnet is definitely receiving hacktivist commands from a Spanish IP.  However, before, during and after the denial of service attack was launched from this infected machine, it relayed any posted credentials made by the user from a web browser.  In fact, in the same second that it received its commands to begin the attack, it posted encrypted Yahoo mail credentials (the user had just then logged into Yahoo) back to a separate command and control server at  Meanwhile, it's pulling a "feed" from malicious domain paradulibo.net ( which gives it a batch of click fraud to start with SEO keyword "1 year lpn schools georgia" and the faked referrer of "porninlinks.com."

Just as cloud providers provide multitenancy models to maximize hardware efficiency, the botnet masters are renting out their services to more and more customers.  This makes it impossible to use characteristics of an infection vector, payload, or even bot agent code as an indicator of what threat the compromised asset poses to the business.  It could launch a denial of service attack, steal passwords, initiate click fraud, or all three at the same time.  It may also be conducting industrial espionage, but I have yet to find an instance of that in the wild.

This is compounded by the fact that the criminals in charge of running the exploit kits such as Blackhole, Scalaxy, Incognito, etc. (which share much of the same codebase), are separate entities from those that actually use the bots.  For instance, here's the infected asset, having just been compromised with a Blackhole kit, checking in to credit the exploit kit admin with a new install:

GET /api/stats/install/?&affid=56300&ver=3040003&group=sf HTTP/1.1
Accept: *//*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB0.0; .NET CLR 1.1.4322)

This is on completely separate infrastructure from the rest of the botnet and represents the segregated "duties" of the criminals.  One is in the business of getting an agent loaded on a host, for which he is paid a small sum on a per-host basis, the other is in the business of using these agents to rent out in the multitenancy model described above.

This can create a real problem when trying to summarize an incident for the customer or for management, because what may start as a simple adware install could have the potential for any part of the cybercrime spectrum.  It also presents a difficult situation for defenders:  It's easy to identify the adware and declare the case closed, but responders must be diligent and follow-up on all actions the host took while compromised because the presence of adware does not preclude far more nefarious actions.

Above all, this should make it obvious that finding and containing compromises is of paramount importance to the business, because any compromised asset is becoming increasingly available to a growing blackmarketplace of criminal consumers.

Edit (5/10/2012):  Looks like Dancho Danchev has a post showing what the console for this kind of botnet looks like.