« April 2010 · October 2010 »
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
- 15.08.2010: Spam using RU domains - Who's your nameserver?
- 13.08.2010: Binary Whitelisting Service
- 02.08.2010: Of Opinions and Anti-Virus Testing
- 05.07.2010: Lies, Damn Lies, and Botnet Size
- 09.06.2010: Shadowserver Sinkholing domain associated with SQLi attacks on IIS/ASP web servers
Thursday, 22 January 2009
Asprox - It's Baaaaaaack
Like all good zombies, Asprox is back and kicking again. Over on the Silent noise blog, it was pointed out that Asprox was back online. While I had hoped that the death of McColo would have kept Asprox offline, the bad guys managed to bring it back. Some might have called it naive, I like to think I was optimistic.
With Asprox (and its partner, Danmec) back online, it was time to dust off some of the old tools for exploring the network. Some tools didn't work, some did. With part of my toolbox broken, I refined what did work.
Before I dig into the tools and the analysis, it's time for a refresher. Way back in May, before Asprox really even had a name, William Salusky did some kick-ass analysis of something he was calling HydraFlux. His analysis was more of the concept, but it included a lot of details about the inner workings of Asprox/Danmec. He decoded the data returned from the motherships back to their infectees. Go take a look at his work, then come back here, I'll wait.
It's time to talk.
When a host is first infected, it makes a few calls out to the network. Most likely, it's establishing whether or not it has internet connectivity. The routine seems to always be:
- DNS lookup of the A record for ns.uk2.net
- DNS lookup of the A record for www.yahoo.com
- Connection to port 80 of www.yahoo.com
- DNS lookup of the A record for www.web.de
- Connection to port 80 of www.web.de
The port 80 connections are a little unusual. At this stage, the binary initiates the connection, then closes it. It never makes an application level request over port 80 to either www.yahoo.com or www.web.de. It's simply SYN to remote, SYN ACK from remote, ACK to remote. It then sends an immediate RST ACK to the remote, severing the connection.
With internet connectivity established, the binary phones home to one of the motherships. I haven't done the deep analysis, but I assume that the initial seed IP(s) is/are encoded in the binary. The IPs don't stand out in any of the associated files. Our sample keeps reaching out to the same host (203.174.83.75). I assume that if that host is down, one of the others will be tried. The connection to the mothership is in the form of a multipart/form-data POST to /forum.php. It will generally look like this:
Content-Disposition: form-data; name="sid"
${_16DigitNumber}
Content-Disposition: form-data; name="up"
${_6DigitNumber}
Content-Disposition: form-data; name="a_cl"
0
Content-Disposition: form-data; name="p"
80
Content-Disposition: form-data; name="wbfl"
1
Content-Disposition: form-data; name="v"
486
Content-Disposition: form-data; name="ping"
${_16DigitNumber} (maybe network latency?)
Content-Disposition: form-data; name="guid"
%{_GUID}
Content-Disposition: form-data; name="wv"
5#2#2#0#2600#0 (According to William, this looks to be the Windows version)
Content-Disposition: form-data; name="DEBUG"; filename="DEBUG.TXT"
Content-Type: application/octet-stream
<and it uploads a small file of binary data>
Once the mothership receives this post, it responds with a config file that's XOR'd (XOR27) named COMMON.BIN. The structure of this file hasn't changed much from what William first described back in may, except there are is one new parameter. Here's one config I pulled down:
<sid>${_16DigitNumber}</sid> (The sid here is the same as what the client sends the server.)
<block>
<v>
426
</v>
<s>203.174.83.75
58.65.233.17
91.211.64.102</s>
<d_a>67.241.202.212
70.154.82.100
68.121.244.7
66.138.254.46
75.33.36.108
69.221.245.243
68.184.50.147
65.102.56.213
173.16.99.131
173.17.180.79
70.197.62.27
69.14.27.151
151.118.179.50
71.235.251.99
208.104.36.229</d_a>
<d_n>62.219.252.109
212.251.99.197
24.247.215.75
68.197.137.239
72.204.44.232
74.196.121.117
75.156.152.67
24.115.143.61
76.240.151.177
69.119.119.178
24.125.132.200
76.123.193.74
68.6.180.109
67.186.82.157
68.105.25.64
67.38.5.135
75.109.252.245
68.4.124.142
64.205.9.114
98.246.13.66</d_n>
<d_m>58.23.67.58</d_m>
<hls>
/d
/config.php
/logo.png
/script.js
/favicon.ico
/style.js
/hobs
/lib
/b.js
/load.php
/logo.gif
/dummy.php
/pdf.php
/geoip.php
/index.php
/geoip.dat
</hls>
<selfip>${_IP_ADDR}</selfip>
</block>
William explained what most of this file is about. The <s> section is the list of motherships. <d_a> and <d_n> are DNS related. And the <hls> section is what gets proxied by the proxy nodes. Note the /style.js entry: this is malicious javascript that's used to infect unsuspecting drive-by victims. /style.js is what is currently being injected into vulnerable websites.
<d_m>58.23.67.58</d_m> is the new parameter. It looks to have something to do with a mail server configuration somewhere. This particular IP shows up in passive DNS as the following names:
mx1.myonlineaccounts9.abbey-national.com.bin961187076.st37.name mx1.online8.natwest.com.tagid95881.sslcom6.tk mx1.www3.natwest.co.uk.asp8.tk mx1.webexpress4.tdbanknorth.com.asp8.tk mx1.ww6.abbeynational.com.sslid164732639.38lang.tk mx1.www3.cashtransfers.tk mx1.online7.lloydstsb.com.ter2.co.uk mx1.online-business8.lloydstsb.com.sss2.co.uk mx1.webexpress6.tdbanknorth.com.get74.co.uk mx1.ww6.abbeybusiness.co.uk.cfm36.co.uk mx1.ww2.natwest.com.cfm36.co.uk mx1.ww5.natwest.co.uk.lan81.com mx1.base62.com mx1.ww7.chase.com.cert83.com mx1.welcome4.co-operativebank.co.uk.bank84.com mx1.welcome9.co-operativebank.co.uk.sid36.com mx1.www.mortgageeunion.com mx1.online7.lloydstsb.co.uk.rundll503613298.hit32.jp mx1.logon57.net mx1.online-business3.lloydstsb.co.uk.c75.su mx1.online-business0.lloydstsb.com.c75.su mx1.www0.lloydstsb.co.uk.aspx7.su mx1.online-business5.lloydstsb.com.f48.su mx1.online-business8.lloydstsb.com.f48.su mx1.www0.lloydstsb.co.uk.aspx9.su mx1.online1.lloydstsb.com.vvb.su
Mmmm, smells like phish! That said, I'm not entirely sure what this <d_m> is for.
While looking into <d_m>58.23.67.58</d_m>, let's look at the primary infrastructure related IPs and see what we find:
58.23.67.58 | 4837 | 58.22.0.0/15 | CHINA169
| CN | - | QUANZHOU CITY FUJIAN PROVINCIAL NETWORK OF CNCGROUP
203.174.83.75 | 38001 | 203.174.80.0/21 | NEWMEDIAEXPRESS-AS
| SG | NE.COM.SG | MIZUWORK SINGAPORE
58.65.233.17 | 23898 | 58.65.233.0/24 | HOSTFRESH-AS
| HK | MYRDNS.COM | HOSTFRESH
91.211.64.102 | 48511 | 91.211.64.0/22 | URALCOMP
| UK | AXIOM.GR | EU-ZZ
There you have it, most of what this arisen Asprox/Danmec will do when it infects a client. There is a little more, though. During a couple observations, I got back a <ml> config section from the mothership. William documented this pretty well here. I'm not going to list the whole <ml> section, as it's not really different than what William found, but here's a few highlights.
<ml>
.co.uk
alicia.green@hotmail.co.uk
alicia.greenberg@craigco.cc
alicia.gregg_ip@jameshutchison.co.uk
alicia.gregory@axa-ppp.co.uk
alicia.griffin@capio.co.uk
alicia.griffin@kdevereux.co.uk
alicia.griffin@ntlworld.com
alicia.griffiths@magnox.co.uk
alicia.griggs@pinnacol.com
alicia.grillot@yahoo.co.uk
alicia.grimesvd@tiltedhalo.co.uk
alicia.groarke@btopenworld.com
{... a whole lot of alicia's. Every line is alicia.something}
</ml>
<wid>
449004026
</wid>
<bcc>
0
</bcc>
<mbody>
Message-ID: <%%MSGID%%>
From: %%FROM%%
To: <%%RCPT%%>
Subject: %%SUBJ%%
Date: %%DATE%%
MIME-Version: 1.0
Content-Type: multipart/alternativeESC
boundary="%%BND:1%%"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
This is a multi-part message in MIME format.
--%%BND:1%%
Content-Type: text/plainESC
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Air crash investigation continues
--%%BND:1%%
Content-Type: text/htmlESC
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/htmlESC charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2722" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
Air crash investigation continues
</BODY>
</HTML>
--%%BND:1%%--
Notice that there's no place in the template for a URL or anything. I only managed to get this config file twice from a mothership, but neither one had a place for a URL. I think this was a test rather than a real run. It wouldn't accomplish anything to send it as is.
There's then a section for dealing with the HELO step of sending email. Lots of handling for graylisting and blacklists and that sort of thing. This is exactly the same as what William saw. Following the <smtprules> section is some more templating and variables:
<from> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%% %%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%% %%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%% %%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%SURNAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%%" <%%LOGIN%%@%%DOMAIN%%> "%%NAME%%" <%%LOGIN%%@%%DOMAIN%%> </from> <subject> Mourners celebrate lives of slain Hudson relatives Afghan Farmers Shift To Mint, Melons Court Clears Way For Jagger Eviction The Last Take Transcript: Sen. Obama, Part 1 Police: Bombings kill 9, wound at least 33 in Iraq Mourners celebrate lives of slain Hudson relatives Politician Freed From Colombian Rebels Bush intervenes in Ohio Third parties unlikely to spoil presidential race Heathrow terminal opening was 'national embarrassment': MPs Thousands Of Coloradoans Win Back Vote GMAC seeks bank status for rescue funding: report Orange halls damaged in attacks US military: 40 tons of Afghan dope destroyed </subject> <domain> 0500.com woman-legalaid.org.cn abcconsultants.net vip163.com lixiaowen.com stiaad.com sz-printing.com ys.lonbon.cn hddz.com.cn firstcp.sh.cn email.cq.cn mandarinlc.com countryclubchennai.in valves.com.cn www.sejie.net.cn mail003.ownmail.com fzhhouse.com ctbweb.cn wwwrediff.co.in m0bo.cn </domain> <login> hatmrt kloxley toeck paynev elsterm goyie jcacapital cdcds ekoco bvelarde noachasson delandjackie faithui highwaystar ksantone ellsley bynry dqfcp pietroarce bzvjj </login> <name> Cerise Antony Guyllum Rupert Uriel Lane Marlin Robby Rosemarie Georgette Scottie Marisol Corey Dewey Maryann Jamie Alisha Clarice Varette Myrna </name> <surname> Saale Filashin Boedecker Greeson Labreche Napp Buzard Colkett Lorino Rogerson Benton Oneal Chapen Pitfield Berberich Sperle Lennan Schoppe Arbuthnot Elkind </surname> </block>
(Still here?)
As we can see, they've updated their ability to have a lot of options for the From: field in the emails this thing will eventually send. We can also see that their first round of subjects are all English (when William looked, the template he saw looked to be Polish). The subjects themselves are all topical and likely pulled from the titles of news items found through a search engine.
Right now, they seem to be building their botnet again. However, it looks like all the infrastructure is back online and they're gearing up to start spamming.
What can you do? A very easy thing is to filter and alarm on any outbound access to the motherships. Someone smarter than me could come up with a snort signature to match the POST to /forum.php. Beyond that, make sure your clients are patched and don't get infected by the drive-bys.
=>Posted January 22, 2009, at 01:19 PM by Mike Johnson
