My Road to Digital Forensics Excellence

Archive for August, 2009

msrll concluded

Posted by Paul Bobby on August 5, 2009

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 0x40BD04. That’s where I set my breakpoint.

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

imageSet 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.

image 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[.]
  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

Posted in Reverse Engineering | Leave a Comment »

msrll continued

Posted by Paul Bobby on August 3, 2009

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 0x409D94.


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 0x410B76. 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: 0x409E1E, 0x409E47 and 0x40A400. I took a look at 0x409E1E first, and turns out this is the correct place to start. Here’s the flow:”

  1. Call to createfile()
  2. Call to function 0x40B2B0 with the following on the stack
    1. 0022EE50 003E4278 Arg1 = 003E4278 ASCII “set”
    2. 0022EE54 0022EE80 Arg2 = 0022EE80 ASCII “”
    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 0x40B2b0 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:

imageAfter 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,!,

   4: set irc.chan #mils

   5: set pass $1$KZLPLKDf$W8kl8Jr1X8DOHZsmIp9qq0

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

Posted in Reverse Engineering | Leave a Comment »

msrll.exe visits #mils

Posted by Paul Bobby on August 3, 2009


During the course of the recently taken Reverse Engineering class, Lenny encouraged us to practice our skills on a variety of malware that he had included on the class CD. This post is based on the specimen, msrll.exe (MD5: B4ACFE96A98590813413122C12C11AAA) (41,984bytes)

My analysis took 12 steps:

  1. Simple Execution
  2. Live Analysis Part 1
  3. Live Analysis Part 2
  4. Live Analysis Part 3
  5. Analysis Goals
  6. Static Analysis – Unpacking
  7. Static Analysis – First look
  8. Static Analysis – Command analysis
  9. Static Analysis – jtram.conf
  10. Static Analysis – Interaction with port 2200
  11. Static Analysis – Interaction in IRC channel
  12. Incident Response

One of the things I learned during this exercise is the value of the baby step approach – thinking you know what’s happening, leaping ahead and assuming too much, gets me in to trouble. Another lesson learned is that after live analysis is complete, I had to identify a series of analysis goals. With this specific specimen I found myself getting bogged down in the encryption routines, achieving no real progress, so I backtracked, and identified exactly those aspects of this malware I needed to explore.

Simple Execution

Running the program, msrll.exe from C:\Temp produced no visible output. After a few seconds the file disappeared from C:\Temp.

Live Analysis Part 1

  1. Wireshark showed a DNS query for collective7[.]
  2. Regshot showed the following items of interest
    1. HKLM\SYSTEM\CurrentControlSet\Services\mfm key added
    2. HKLM\SYSTEM\CurrentControlSet\Services\mfm\security key added
    3. Various key-value pairs added
      1. ImagePath = “C:\Windows\system32\mfm\msrll.exe”
    4. Files added
      1. system32\mfm\jtram.conf (contains obfuscated text)
      2. system32\mfm\msrll.exe
  3. CaptureBAT.exe
    1. preserved the deleted file msrll.exe from C:\Temp
    2. Both msrll.exe specimens MD5 match
  4. Process Explorer
    1. msrll.exe executing from system32\mfm\msrll.exe
    2. msrll.exe listening on two ports
      1. TCP 113 (Auth identd)
      2. TCP 2200

Live Analysis Part 2

  1. A host entry in system32\drivers\etc\hosts was made to resolve collective7[.] to my Linux VM.
  2. Wireshark reports a connection attempt on port 6667

Live Analysis Part 3

  1. Fire up IRCD on the Linux VM
  2. msrll.exe connects to the IRC daemon
  3. Wireshark lights up with the following activity
   1: USER PKjlVumLCrI localhost 0 :xIzUYurlIIlnEpkWTWTLmKmxpEjwTR



   4: JOIN #mils :

   5: MODE #mils

   6: WHO #mils

   7: PONG :localhost.localdomain

   8: PONG :localhost.localdomain

Analysis Goals

  1. What is in the file “system32\mfm\jtram.conf”?
  2. Interact with what is listening on port 2200
  3. Interact with the IRC bot
  4. Incident Response
    1. 4n6 indicators
    2. Network indicators leading to mitigations

Posted in Reverse Engineering | Leave a Comment »