Post Fri Aug 24, 2007 11:42 pm

Skillz June 07 Winning Entry - Technical

Phillip Ames

1. What tool did Kaylee use to remove the malware?  How could she find
the process, kill it and keep it from starting?

Kaylee's thumbdrive contained the tools provided in SysInternals “PsTools” suite.

pslist - list processes that are running ... sList.mspx
pskill - kill by process name or process id ... sKill.mspx
psservice - enable/disable services ... rvice.mspx
autoruns – examine autorun configuration ... oruns.mspx

First, she would want to identify the malware program.  The easiest way to do this would be to run 'pslist' and find the Process ID (PID) for the malware using the 'elapsed time' field as a way to narrow the search domain.  The malware process would have been running roughly the amount of time since the beam hit the ship (when infection presumably occurred).

Kaylee's second step would be to use the 'pskill -t' command using either the PID or process name obtained from 'pslist' (PID is safer) to terminate the malware process.  The '-t' flag would kill any child processes of the malware (just in case).

The third step for Kaylee's cleanup would be to use the 'psservice config' command.  Outputting this to a file (‘psservice config >
services.txt’) and then using notepad to search for the suspect executable (identified in the first step) will let the crew know if the malware has been deposited on the nav computer as a service.  The BINARY_PATH_NAME displays the malware executable name and location.  The malware will automatically start with Windows if the START_TYPE is set to 'AUTO_START'.  The malware service can be disabled with a 'psservice setconfig <servicename> disabled'.

If the malware has been designed to spawn using the 'svchost' program, further investigation of the registry becomes necessary to locate the

The key:

will contain the location of the malware executable.

Kaylee may also want to use Autoruns (another SysInternals tool) to make sure that nothing unexpected will launch on startup.

2. What was the code snippit most likely used for and what was the bot's
control password?
After recognizing that the code snippet is innocuous instructions(only MOV, no CALL), the quickest way to see what this code does is to run it.
Copying and pasting the code into a '.asm' file and adding the appropriate ASM fragments to it to make it a complete program (data & text declarations that we can assemble and link) yields this information.  The purpose of the code was most likely to (in an obfuscated fashion) set the control password for the bot.  It's most likely not hard coded so that cursory examination with the 'strings'
command does not show the password (since it never appears as a null-terminated string in the executable).

Since all MOV's are relative to the EAX register, Kaylee will create an empty variable in memory and put its location in EAX so she can see what gets placed there by the assembly instructions.  She will also append a NOP to later use as a breakpoint with GDB.  Then, she can use GDB's ability to examine memory contents on the address of the dummy variable pointed to by EAX to see what the code placed there.  The final ASM file
(malware.asm) looks like this (in NASM syntax):

section .data
        string: db "" ; create a dummy variable named 'string'

section .text

global main

main: ; define the entry point for the program
    MOV EAX,string ; place the address of 'string' in EAX
    MOV BL, 0x4d
    MOV [EAX + 0x00], BL
    MOV BL, 0x21
    MOV [EAX + 0x0d], BL
    MOV BL, 0x73
    MOV [EAX + 0x09], BL
    MOV BL, 0x61
    MOV [EAX + 0x01], BL
    MOV BL, 0x6f
    MOV [EAX + 0x04], BL
    MOV BL, 0x6c
    MOV [EAX + 0x03], BL
    MOV BL, 0x74
    MOV [EAX + 0x0c], BL
    MOV BL, 0x79
    MOV [EAX + 0x06], BL
    MOV BL, 0x72
    MOV [EAX + 0x05], BL
    MOV BL, 0x57
    MOV [EAX + 0x07], BL
    MOV BL, 0x61
    MOV [EAX + 0x08], BL
    MOV BL, 0x6c
    MOV [EAX + 0x02], BL
    MOV BL, 0x48
    MOV [EAX + 0x0a], BL
    MOV BL, 0x6f
    MOV [EAX + 0x0b], BL
    NOP ; to be used as a breakpoint
Now, Kaylee will assemble and link this program on her Linux machine in the (E)xecute and (L)ink (F)ormat to analyze it (alternatively, she could use a Windows assembler and OllyDbg).  The commands she enter will:
- -disassemble the main function (showing her the address of the NOP instruction she needs to set a breakpoint at to ensure all the malware commands execute) – GDB 'disassemble main'
- -set a breakpoint at the NOP instruction – GDB 'break *0xaddress'
- -run the program – GDB 'run'
- -examine the memory at EAX to see what the malware placed there – GDB 'x/s $eax'

kaylee@serenity ~ $ nasm -f elf malware.asm kaylee@serenity ~ $ gcc -o malware malware.o kaylee@serenity ~ $ gdb malware GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc.
(gdb) disassemble main
Dump of assembler code for function main:
0x08048360 <main+0>:    mov    $0x80495a4,%eax
0x08048365 <main+5>:    mov    $0x4d,%bl
0x08048367 <main+7>:    mov    %bl,(%eax)
0x080483a5 <main+69>:  mov    $0x6f,%bl
0x080483a7 <main+71>:  mov    %bl,0xb(%eax)
0x080483aa <main+74>:  nop
0x080483ab <main+75>:  nop
End of assembler dump.
(gdb) break *0x080483aa
Breakpoint 1 at 0x80483aa
(gdb) run
Starting program: /home/kaylee/malware
Breakpoint 1, 0x080483aa in main ()
(gdb) x/s $eax
0x80495a4 <completed.1>:        "MalloryWasHot!"

3. Describe how you could discover the commands the bot would accept and
their basic functionality?
Static analysis is probably best suited for determining this information.  Using commands like ‘strings’, a list of potential commands can be generated (assuming they were not obfuscated in the same manner the control password was).  Finding a list of candidate strings and their offsets in hexadecimal is shown below:
kaylee@serenity ~ $ strings --radix=x malware
    134 /lib/
    1d7 _IO_stdin_used
    1e6 __libc_start_main
    1f8 __gmon_start__
    207 GLIBC_2.0
    298 PTRh
    2a5 QVh`
    3ef [^_]
    5a4 aaaaaa

Here, the string ‘aaaaaa’ is located at offset 0x5a4 – this can be verified using the ‘hexdump’ command.  Some extra information is shown due to the 16 byte count (-n 16) .  An ASCII translation is also provided (-C)

kaylee@serenity ~ $ hexdump -s 0x5a4 malware -n 16 -C
000005a4  61 61 61 61 61 61 00 00  00 47 43 43 3a 20 28 47
|aaaaaa...GCC: (G|

Some of the commands may provide insight to their functionality just in the name alone (for example, “udp_dos” might be a command to launch a Denial of Service attack using UDP packets).  For commands that are cryptic in name, more investigation is necessary.  A list of functions can be obtained by running ‘gdb <malware>’ and then ‘info functions’.

kaylee@serenity ~ $ gdb malware
GNU gdb 6.6

(gdb) info functions
All defined functions:

Non-debugging symbols:
0x0804824c  _init
0x08048274  __libc_start_main@plt
0x08048290  _start
0x080482b4  call_gmon_start
0x080482e0  __do_global_dtors_aux
0x08048320  frame_dummy
0x08048360  main
0x080483ac  __libc_csu_init
0x080483f4  __libc_csu_fini
0x08048446  __i686.get_pc_thunk.bx
0x08048450  __do_global_ctors_aux
0x08048480  _fini

Functions can be analyzed in assembly by using the ‘disassemble <function name>’ command or by setting breakpoints on a running malware process (‘break <function name>’ or ‘break *0x080…’ to break at a specific address).

4.  (Extra Credit)  What is the meaning of the password?
The password is based off the movie “Bloody Mallory”, which is described as a cross between Buffy the Vampire Slayer (created by Firefly’s creator, Josh Whedon) and Resident Evil.  Mallory (played by Olivia
Bonamy) is the main character:

Posted by Don.