Ethical hacker challenge - Serenity

I didn't win the latest ethical hacker challenge, one of the reasons being the lack of my film-trivia knowledge. So here goes my answer to the challenge, maybe somebody finds it useful. You can also compare it with the winning submission.

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

The label on the thumb-drive (at least what is visible from it, "SysIn...") is most probably a reference to the great free utilities created by SysInternals, who have recently been bought by Microsoft, but the utilities are mostly still available in their original from at http://www.microsoft.com/technet/sysinternals/default.mspx

One of the best ways to get to know the tools is to watch the presentation given by Mark Russinovich himself at http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=359 (free registration required, but there is a back door: http://forum.sysinternals.com/forum_posts.asp?TID=9409&PN=1). What follows below is a very short presentation of the tools, but realistically one should watch the whole presentation to get a good feel of them.

- ProcessExplorer - is the swiss army knife.

When using it look for malware, it is useful to turn on the "Company Name" and "Description" columns and look for executables with similar names but slightly different descriptions (one trick malware authors frequently use is to name their executable similar to the operating system components - for example lsass.exe - but many times they have no attention to details). For example if you see 5 instances of svchost.exe all having "Microsoft Corporation" in their company name and one having "Microsoft", it is a clear indication that something is not right.

In the same manner one should examine the icons associated with each executable (which ProcessExplorer readily displays) and look for any discrepancies (many times malware authors use ready-made tools to generate their executable - like archivers capable of generating self-extract archives with installation scripts or scripting languages which can "compile" into an executable and don't bother or don't know how to change the icon).

Also, one should look at the location where the executable is running from (to use the prior example: if 5 instances of svchost.exe are running from %windir%\system32 and one from %windir%\system, it is very suspicious). This technique is quite common, and exploits a limitation of the Task Manager built into windows, namely that it can't display the path where the executable is running from, making the six instances described in the example indistinguishable from one-another.

An other clues to look for are executables with characters in their name which are easy to confuse with other characters (for example instead of lsass.exe one migh see 1sass.exe of Isass.exe - the last one uses the big "i" character which in some fonts is indistinguishable from the small "L" character).

Yet an other indication of malware are processes which are "packed". They are highlighted in purple by default in ProcessExplorer. However, one must not assume that any "packed" process is an indication of malware, since many other programs - for the worst of for the better - employ packers. It is however a sign to further investigate.

As a general rule one should look for processes which one doesn't recognize (assuming that one has an experience with the processes which should run under "normal" conditions) and investigate those processes (again, they should not be assumed to be malware from start, because killing the wrong process / deleting the wrong file can render the computer unusable).

Also, if a malware process has been identified, its parent / child processes should also be examined carefully, since many times malware processes launch / are launched by other malware components.

When the malware process has been identified (by the steps described earlier or described in the next paragraphs or by other means), ProcessExplorer can be used to terminate it. It is recomended to first suspend all the processes which are going to be terminated and then terminate them to circumvent the self protection mechanisms present in some malware, where processes watch each other and restart any killed process.

- TCPView - a visual equivalent of netstat (the same functions can be performed by netstat in recent windows version - by using the the "-b" command line switch - however it is more convenient when doing interactive examination)

It can be downloaded from http://www.microsoft.com/technet/sysinternals/Networking/TcpView.mspx and it can be used to identify processes which make unrecognized connections (again, this step also need a level of familiarity with the normal operation environment). ProcessExplorer can also display the network connections of a process, however it does not offer an overview of all the connections.

In this particular case one should look for connections with a target port of 6666 or 6667 which are traditionally the IRC ports.

- Autoruns - Downloadable from http://www.microsoft.com/technet/sysinternals/utilities/Autoruns.mspx, it is the ultimate tool to identify all the processes which are registered to start when Windows is launched (similar to the built-in msconfig, however much more similar). While there are ways to run an executable at startup which are not covered by this utility (for example some malware infects program which are registered to start-up and injects code to start itself), it covers most (I would guestimate 99%) of the possible ways to start a program.

The utility can be used both to view and to modify the startup lists (by disabling programs). One useful feature it has is the possibility to hide signed Microsoft executables, which reduces the number of elements one must go through considerably (again, this feature is not 100% foolproof, since malware can - and indeed some do - install a custom root certificate on the system and from then on "sign" whatever executable / ssl connection it pleases, but it works most of the time)

2. What was the code snippit most likely used for and what was the bot's control password?

It is used to build a string dynamically by using indirect addressing (with the EAX register holding the base address). This (and similar) tricks have been used lately to circumvent the "strings" analysis (which refers to a *nix utility ported to windows by sysinternals - http://www.microsoft.com/technet/sysinternals/Miscellaneous/Strings.mspx) which can extract strings from arbitrary binary files by looking for continious runs of printable characters. These obfuscation techniques work by "breaking up" the characters and reconstructing the string only at runtime. The ProcessExplorer mentioned at point 1 includes the possibility to run the "strings" algorithm on the memory space of the live process, thus circumventing these techniques.

When a technique is observed, one can create patterns to extract the string. For example in this case the pattern would be (the opcodes are in hex):

B3 4D MOV BL, 0x4d              
88 58 MOV [EAX + 0x00], BL

If the offset relative is non-zero, the sequence is:

88 58 05 MOV [EAX + 0x05], BL

One could use these patterns to go trough the file and extract any strings. However it is easier to simply run the program in a debugger (in a controlled environment!), to extract the strings from the memory or to sniff the traffic off the wire.

The text hidden in this snippet is "MalloryWasHot!", which was obtained by passing the text through the following perl script (because I'm lazy :) ):

use strict;
use warnings;

open F, "test6.in";
my $v;
my %h;
while () {
    if (/MOV BL, 0x([a-f0-9A-F]+)/) {
        $v = pack('H*', $1);
    } elsif (/EAX \+ 0x([a-f0-9A-F]+)/) {
        $h{$1} = $v;
    }
}
close F;

foreach (sort keys %h) {
    print $h{$_};
}
print "\n";

Because this was the only text given, probably this is also the passsword.

3. Describe how you could discover the commands the bot would accept and their basic functionality?

There are several possibilities:

One could run the malware in a controlled environment (a virtual machine for example) and sniff the traffic with tools like Wireshark or the Microsoft Network Monitor. Because IRC traffic is unencrypted (most of the time), one can learn a great deal this way. However the risk is that the malware (on the command received from the controller) might engage in activities (like spamming or DoS attacks) which are considered illegal and might get the researcher in legal trouble for actively participating in it. These concerns can be mitigated by throtling the upstream bandwith of the analisys environment, however there is no perfect solution. Because of these problems, this method is recommended only for short period of times and with active human monitoring to make sure that rapid intervention is possible.

The second possibility is to join the community of bots, which is especially simple when they use standard protocols like IRC for communication for which there are readily available clients on all platforms. The two methods can be very successfully combined the following way: a short run with traffic sniffer attached is used to extract key elements like:

- the server name / IP

- the channel name and password (if there is one)

- the format of the nickname which is used

After this short preliminary analysis (which is safe because of the short timelength and human monitoring), the malware is disconnected and an IRC client is connected using the gathered data.

4. (Extra Credit) What is the meaning of the password?

It is a reference to the main character Malcolm "Mal" Reynolds I think.