427 Botnet fm qxd

www.syngress.com
364
Chapter 10 • Using Sandbox Tools for Botnets
427_Botnet_10.qxd 1/9/07 3:06 PM Page 364

---

subkey_or_value="Arman" data="C:\WINDOWS\system32\arman.exe"/>
subkey_or_value="SOFTWARE\Microsoft\CTF\Compatibility\arman.exe"/>

Now for the interesting stuff, namely those operations dealing with net-
work connections. Each analysis report for malware that calls at least one
Winsock operation contains a 

.This has several subsections:
one for all UDP connections, one for the incoming TCP connections, one for
the allowed outgoing TCP connections, one for the blocked TCP connec-
tions, and a last one for all operations for which the underlying protocol and
direction could not be determined because no indicating function was called.
These latter sections normally are used for the Windows built-in DNS query
functions. In our case the Winsock notifications section starts like this:







We can see that the first DNS query did not deliver an IP address.This is
because at the moment of the analysis the domain name sexccc.serveftp.com
was not connected to a valid IP. In contrast, the second request for
sexccc.ath.cx delivers the IP 208.98.19.3, which is the address of the botnet
C&C server, as we see here:

remoteport="6666" protocol="IRC" connectionestablished="1" socket="1396">
nick="[XP|DEU|P|00|gcoDZaUz]">
topic_deleted=":.scan.stop -s;.scan.start NETAPI 40 -a -s;
.scan.start NETAPI 40 -b -s"/>



The malware initiates an outgoing TCP connection to 208.98.19.3 on
port 6666, which can be established successfully. Furthermore, CWSandbox