msrll concluded

Static Analysis – Interaction with port 2200

Telnet to port 2200 produces a simple prompt “#:”. There is a single reference to this ASCII string in the code at 0×40BD04. That’s where I set my breakpoint.

On tracing the calling tree that gets to this point, I found a place to modify the runtime credential check.

Set a breakpoint on the highlighted line, change the ZERO flag when you get there, and the code will assume the credentials you typed in at the “#:” prompt are valid.

Static Analysis – Interaction in IRC channel

I first attempted to find where the command “?login” was processed – but hit a dead end. Instead I focused on where the malware processes input received from the IRC channel. The bot issues a periodic IRC PING, causing the client to exit after a 180 Timeout if the PONG is not received. This is a little wrinkle when analyzing the code.

When the username and password are processed, the code tests the results twice: line 405B68 with TEST EAX, EAX and line 405B72 with TEST EAX, 10000. Patching both of these lines with NOPS means a successful login in the IRC channel.

Incident Response

1. DNS Block
   1. collective7[.]zxy0.com
2. SMS Search
   1. system32\mfm\jtram.conf
   2. system32\mfm\msrll.exe
3. Personal Firewall
   1. Block on incoming connections to TCP 2200
4. 4n6 indicators
   1. Registry autorun key
   2. MD5 of executable

msrll continued

Static Analysis – Packed Code

1. PEiD identifies the code is packed using ASPACK v2.12
2. I found a manual unpacking method here
3. I saved the executable once the OEP was reached
4. LordPE was used to rebuild
5. I ran the code through Static Analysis part 2, and observed the same filesystem and registry behavior.

Static Analysis – First Look

1. I reverted to a pristine Windows VM and executed the unpacked msrll.exe
   1. Not interested in analyzing the copy, execute, delete capability
   2. All analysis with Ollydbg conducted against the system32\mfm\msrll.exe file

Static Analysis – Command Analysis

The following commands were observed from a simple strings output

?ssl ?free ?dcc ?clone ?raw ?get ?clones ?update ?say ?login ?hostname ?msg ?uptime ?fif ?sklist ?reboot ?!fif ?unset ?status ?del ?uattr ?jump ?pwd ?dccsk ?nick ?play ?con ?echo ?copy ?killsk ?hush ?move Ping ?wget ?dir Udp ?join ?sums Syn ?aop ?rmdir Smurf ?akick ?mkdir Jolt ?part ?run ?insmod ?dump ?exec ?rmmod ?set ?kill ?lsmod ?die ?killall ?md5p ?crash

Static Analysis – jtram.conf

This file contains a number of obfuscated strings. The string ‘jtram.conf’ was referred to in seven separate locations within the executable. Since the file is created, I decided to find when ‘jtram.conf’ coincides with a call to CreateFile. This happens at 0×409D94.

Setting a breakpoint right after this function call shows jtram.conf created as a 0byte file. So how do you write to a file?

I saw references to the function ‘fprintf()’. This function is called once at 0×410B76. With a breakpoint set just prior to this call, and stepping over, I found that jtram.conf was not populated.

How else do you write to files? I saw references to the function ‘writefile()’. ‘writefile()’ is called from three locations: 0×409E1E, 0×409E47 and 0×40A400. I took a look at 0×409E1E first, and turns out this is the correct place to start. Here’s the flow:”

1. Call to createfile()
2. Call to function 0×40B2B0 with the following on the stack
   1. 0022EE50 003E4278 Arg1 = 003E4278 ASCII “set”
   2. 0022EE54 0022EE80 Arg2 = 0022EE80 ASCII “collective7.zxy0.com”
   3. 0022EE58 00001000
   4. 0022EE5C 004099F5 ASCII “DiCHFc2ioiVmb3cb4zZ7zWZH1oM=”
   5. 0022EE60 77DDF8D2 advapi32.77DDF8D2
3. Call to strcat() with the following on the stack
   1. ESP ==> > 0022EE80 dest = “oQERAPMCsTQme0PcWG9XLjSpzm4MQZ0T+YEOEyEmztL4jtJnUw==”
   2. ESP+4 > 00409A12 src = ” ”
   3. ESP+8 > 00001000
   4. ESP+C > 004099F5 ASCII “DiCHFc2ioiVmb3cb4zZ7zWZH1oM=”
   5. ESP+10 > 77DDF8D2 advapi32.77DDF8D2
4. Call to writefile()
5. “oQERAPMCsTQme0PcWG9XLjSpzm4MQZ0T+YEOEyEmztL4jtJnUw==” then becomes arg1 when 0×40B2b0 is called again

This is the point where I got bogged down. I attempted to reverse the algorithm used to write the obfuscated text to jtram.conf – big mistake. At least at this early stage in my reversing capabilities!

Can we fake out the executable so that it writes jtram.conf in the clear? Yep, change this:

to this:

After executing msrll.exe and waiting 30 seconds or so, I terminated the process, and opened jtram.conf in Notepad. The contents were written out in the clear:

   1: set bot.port 2200

   2: set irc.quit

   3: set servers collective7.zxy0.com,collective7.zxy0.com:9999!,collective7.zxy0.com:8080

   4: set irc.chan #mils

   5: set pass $1$KZLPLKDf$W8kl8Jr1X8DOHZsmIp9qq0

   6: set dcc.pass $1$KZLPLKDf$55isA1ITvamR7bjAdBziX