Sunday, December 23, 2007

Storm-Bot stripshow analysis

Merry Christmas from the RBN. Now on a PC near you, a stripshow from Santa's helpers. Or not.
The ISC reported the expected Storm surge Christmas eve at 0000 GMT.
hxxp://merrychristmas.com/stripshow.exe (modified to protect the innocent) yields a hash of 2BBA62FBC3B9AF85C3C7D64A82E1237C. Once executed it immediately copies itself as disnisa.exe to C:\WINDOWS and adds a startup registry key for the same.

Current AV detection includes:
Kaspersky stripshow.exe - Email-Worm.Win32.Zhelatin.pd.
eTrust-Vet - Win32/Sintun.AT
Microsoft - Trojan:Win32/Tibs.gen!ldr
Symantec - Trojan.Peacomm.D

After a quick time check to Microsoft's time server, this variant switches immediately to very noisy P2P on a variety of ports. In addition to the ISC-recommended HTTP and email blocks for outbound to merrychristmasdude.com, you have to consider if you really need outbound UDP traffic above 1024. I'm a firm believer in deny all and make exceptions only via legitimate business case. If you can achieve such lockdown, even though your hosts may suffer infection, they won't be communicating with their friends and neighbors.
From API analysis we see a few interesting tidbits:

w32tm /config /update
403014 Copy(c:\malware\stripshow.exe->C:\WINDOWS\disnisa.exe)
77e6bc59 WriteFile(h=7a0)
403038 RegOpenKeyExA (HKCU\Software\Microsoft\Windows\CurrentVersion\Run)
40305f RegSetValueExA (disnisa)
402ba0 WinExec(w32tm /config /syncfromflags:manual /manualpeerlist:time.windows.com,time.nist.gov,100)
77e7d0b7 WaitForSingleObject(788,64)
402ba8 WinExec(w32tm /config /update,100)
40309b CreateProcessA(C:\WINDOWS\disnisa.exe,(null),0,(null))
4030df WinExec(netsh firewall set allowedprogram "C:\WINDOWS\disnisa.exe" enable,100)
71ab52c6 LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
71a5716a LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
71aa14eb GlobalAlloc()
40da1b bind(8c, port=26790)
77e7ac53 CreateRemoteThread(h=ffffffff, start=404b05)
40da1b bind(b8, port=7018)
40d9c7 listen(h=b8 )
40a262 WaitForSingleObject(d4,2710)

Nice, do a little time sync, allow ourselves through the firewall, then bind, listen, and wait.
First, add another registry entry,

0cd2d RegCreateKeyExA (HKLM\Software\Microsoft\Windows\ITStorage\Finders,)

then start connecting:

71a54cee LoadLibraryA(C:\WINDOWS\system32\mswsock.dll)=71a50000
77e7ac53 CreateRemoteThread(h=ffffffff, start=71a519c4)
40d9f1 connect( 193.33.146.178:24714 )
40d9f1 connect( 74.60.173.98:3887 )
40d9f1 connect( 58.74.135.13:30843 )
40d9f1 connect( 222.119.113.135:22295 )
40d9f1 connect( 71.234.220.147:20232 )
40d9f1 connect( 76.84.231.43:14172 )
40d9f1 connect( 124.5.147.194:16544 )
40d9f1 connect( 58.8.236.130:13224 )
40d9f1 connect( 190.79.151.75:2952 )
40d9f1 connect( 58.8.122.191:29646 )

Once this little bugger hits the network, expect flood-like traffic.
My infected sandbox victim exhausted my 1.5mb DSL connection instantly, in part from a ton of inbound responses from peers being logged at my firewall:

SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=59178 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=60978 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=4987 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=6619 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=13762 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=18384 PROTO=UDP SPT=24045 DPT=26790 LEN=33
SRC=78.166.75.60 DST=192.168.0.3 LEN=53 TOS=0x00 PREC=0x00 TTL=105 ID=19891 PROTO=UDP SPT=24045 DPT=26790 LEN=33

At last, the peer list referred to by the ISC, written to C:\WINDOWS (many more entries not included):

[config]
[local]
uport=20142
[peers]
00003D6C8F338A3FDD3DF3648666F55C=0CCE03EE2BD100
0100A634122F3553A046EC451061927C=0CCEEF9C5BF700
02007E238D780D25FD5511285E2E596E=0CD9D73081A500
03001E62DC533E7AF6161729A953891B=180BB9671B4800
0400EB5EC13599373A3D544A2D6AF94F=180FAC024F7300
05004710B3440F5D2117CE555A62D04A=1810D0AE22DA00
06001471521206296D099433C93EC427=1813911C2E6100
07002D6D5B0FE3019C56B1290A564E59=1820B08043D700
0800A2417153943DC23C6C5C817C4159=18257B254F2600


There's nothing new or exciting here: SPAM component, headless P2P, seasonal social engineering, fast flux, and other pervasively annoying attributes.
User awareness, as always, is your strongest defense.
Cheers and happy holidays, except for you RBN a$$h0735.

Storm-Bot stripshow analysis at del.icio.us Digg Storm-Bot stripshow analysis

6 comments:

Ismael said...

Excellent analysis and post. The bad guys don't take a holiday break. glad to see you don't either...

--A Grateful InfoSec Peer...

Jim Manico said...

Than you for taking the time to provide such an in-depth analysis. Keep up the great work and Happy Holidays!

syn-ack said...

Thank for the great analysis work and write up, your post has been invaluable. Merry Christmas and Happy New Year!

Michael said...

The bad guys don't take a holiday break because they want to infect all those shiny new boxen people are giving each other. Christmas is bonus time!

I haven't actually seen any of these coming in yet. What a shame. (Although I've been starting to block all DSL IP blocks, so maybe that's actually starting to work...)

Zeeshan Muhammad said...

Hi Russ,

What application(s) and methods did you use to produce the above dump that shows the API calls?

I currently use BindView's Win32 port of strace/truss and some other tools, but haven't seen such verbose API information before.

Would you be as kind as to inform us of your tools? :-)

- Zeeshan

Anonymous said...

Excellent work, I'v adjusted my incoming filters to suit.