Thankfully, the owner of the server was very interested in my offer of assistance with their server, so I was able to do more digging!
So, it was a Debian Linux server running sending a lot of source-spoofed packets onto the network. My first step was to get access back to the server remotely, to make life easier. This was simple; two iptables rules to block all packets to our two destination hosts:
iptables -I OUTPUT -d aaa.bbb.37.10 -j DROP
iptables -I OUTPUT -d aaa.bbb.38.140 -j DROP
This quickly stopped the outgoing packets and made the server remotely accessible.
Next up, checking netstat gave no obvious connections to these IPs. However, knowing they are spoofed, this was actually the wrong place to look. The offending process was almost certainly using a raw socket. So:
~# netstat -anp | grep raw
raw 0 0 0.0.0.0:1 0.0.0.0:* 7 2666/dhcpd
raw 0 0 0.0.0.0:255 0.0.0.0:* 7 9060/0]
raw 0 0 0.0.0.0:255 0.0.0.0:* 7 28477/0]
There were three processes with raw sockets open, dhcpd, and two unnamed ones. Knowing that dhcpd was legitimate, the two other processes needed looking at. A quick run of "top" showed me that one of them was consuming *way* too much CPU!
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9060 root 20 0 1836 300 196 R 101 0.0 642:44.59 migration
It seemed a bit strange that the process was called "migration" as this is a standard Linux process. However, the real migration process would have a low pid as it is a system process started at boot. The other process was also called migration and also had a high pid, but this time without the high cpu. So, I paused both processes, without terminating them, to enable further analysis.
kill -STOP 9060
kill -STOP 28477
Another new trick I learned, which to many of you will be no surprise, is that you can simply and easily access a copy of the running application even if it has removed itself from the disk. Looking in /proc/<pid> I could see:
~# cd /proc/28477
/proc/28477# ls -l
total 0
dr-xr-xr-x 2 root root 0 Jan 28 12:12 attr
-r-------- 1 root root 0 Jan 28 12:12 auxv
-r--r--r-- 1 root root 0 Jan 28 12:12 cgroup
--w------- 1 root root 0 Jan 28 12:12 clear_refs
-r--r--r-- 1 root root 0 Jan 27 01:27 cmdline
-rw-r--r-- 1 root root 0 Jan 28 12:12 coredump_filter
-r--r--r-- 1 root root 0 Jan 28 12:12 cpuset
lrwxrwxrwx 1 root root 0 Jan 28 11:30 cwd -> /usr/sbin/ttyload
-r-------- 1 root root 0 Jan 28 12:12 environ
lrwxrwxrwx 1 root root 0 Jan 26 06:25 exe -> /usr/sbin/ttyload/migration (deleted)
dr-x------ 2 root root 0 Jan 28 11:30 fd
dr-x------ 2 root root 0 Jan 28 11:30 fdinfo
-r-------- 1 root root 0 Jan 28 12:12 io
-r-------- 1 root root 0 Jan 28 12:12 limits
-rw-r--r-- 1 root root 0 Jan 28 12:12 loginuid
-r--r--r-- 1 root root 0 Jan 28 11:30 maps
-rw------- 1 root root 0 Jan 28 12:12 mem
-r--r--r-- 1 root root 0 Jan 28 12:12 mountinfo
-r--r--r-- 1 root root 0 Jan 28 12:12 mounts
-r-------- 1 root root 0 Jan 28 12:12 mountstats
dr-xr-xr-x 8 root root 0 Jan 28 12:12 net
-rw-r--r-- 1 root root 0 Jan 28 12:12 oom_adj
-r--r--r-- 1 root root 0 Jan 28 12:12 oom_score
-r--r--r-- 1 root root 0 Jan 28 12:12 pagemap
-r--r--r-- 1 root root 0 Jan 28 12:12 personality
lrwxrwxrwx 1 root root 0 Jan 28 11:30 root -> /
-rw-r--r-- 1 root root 0 Jan 28 12:12 sched
-r--r--r-- 1 root root 0 Jan 28 12:12 sessionid
-r--r--r-- 1 root root 0 Jan 28 12:12 smaps
-r--r--r-- 1 root root 0 Jan 28 12:12 stack
-r--r--r-- 1 root root 0 Jan 27 01:26 stat
-r--r--r-- 1 root root 0 Jan 27 01:26 statm
-r--r--r-- 1 root root 0 Jan 27 01:27 status
-r--r--r-- 1 root root 0 Jan 28 12:12 syscall
dr-xr-xr-x 3 root root 0 Jan 28 11:43 task
-r--r--r-- 1 root root 0 Jan 28 12:12 wchan
So the "exe" symlink pointed to the original file on disk, but told me that it had now been deleted. However, the file was still in memory, so I was able to copy it and start looking at it!
/proc/28477# cat exe > /tmp/thing
/proc/28477# file /tmp/thing
/tmp/thing: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
Looking further at what strings it contained (IP address hidden!):
# strings /tmp/thing
--snip--
aa.bb.ccc.251
ircd.exampledomain.net
privmsg %s :CHECKSUM <on/off>
privmsg %s :Checksum has been turned on.
privmsg %s :Checksum has been turned off.
privmsg %s :DNS <host>
privmsg %s :Resolving %s...
privmsg %s :Unable to resolve.
privmsg %s :Resolved to %s.
privmsg %s :%d.%d.%d.%d
privmsg %s :%d.%d.%d.%d - %d.%d.%d.%d
privmsg %s :White Knight 2012
privmsg %s :NICK <nick>
privmsg %s :Nick cannot be larger than 50 characters.
NICK %s
privmsg %s :Removed all spoofs
privmsg %s :What kind of subnet address is that? Do something like: 169.40
privmsg %s :BYSIN <target> <port>
privmsg %s :Packeting %s.
privmsg %s :SLICE <destination> <lowport> <highport>
privmsg %s :Error in SLICE2: Low > high.
privmsg %s :PAN <target> <lowport> <highport>
privmsg %s :Talking %s ...
privmsg %s :This knight accepts the following commands via ctcp (with a #):
privmsg %s :NICK <nick> = Changes the nick of the knight
privmsg %s :GETSPOOF = Gets the current spoofing
privmsg %s :SPOOFS <subnet> = Changes spoofing to a subnet
privmsg %s :DNS <host> = DNSs a host
privmsg %s :CHECKSUM <on/off> = Turns checksum on or off
privmsg %s :IRC <command> = Sends this command to the server
privmsg %s :SH <command> = Executes a command
privmsg %s :KILLALL = Kills all current packeting
privmsg %s :KILL = Kills the knight
privmsg %s :DISABLE = Disables all packeting from this knight
privmsg %s :ENABLE = Enables all packeting from this knight
privmsg %s :VERSION = Requests version of knight
privmsg %s :HELP = Displays this
kill -9 %d;kill -9 0
privmsg %s :Killing pid %d.
--snip--
So it was fairly obviously an IRC bot, with the main goal of sending spoofed DOS attacks. It also had the ability for the controller to execute arbitrary shell commands, which in this case would be run with root privilege. Therefore, it could be used to insert further malware.
I have since been playing a little with this bot in a sandbox, but that is for a later post.
Hope you found that interesting, it was a bit of a rushed post. I hope you find it an encouragement to do some of your own malware analysis!
