This live DVD is a remastered version of Ubuntu 10.0 Beta LTS x86_32. It was designed due to my being disappointed with another reverse engineering malware live CD that was released recently. I have decided to call my creation MERCURY, which is an acronym for Malware Enumeration, Capture, and Reverse Engineering.

The Mercury live DVD contains tools used for digital forensics, data recovery, network monitoring, and spoofing. It should primarily be used as a honeypot or network monitoring platform as well as a laboratory and teaching aid. There are three honeypots installed – honeyd, nepenthes, and dionaea. Four, if you include netcat.

The majority of the additional applications reside in /opt:

• Dionaea (0.1.0) – Dionaea is a malware collection honeypot focusing primarily on SMB emulation, covered on InfoSanity numerous times before.
• FFP – Fuzzy Fingerprinting is a util to aid SSH MitM attacks.
• jsunpack-n – Is a Javascript unpacker, perfect for analysis captured or potentially malicious URLs in more depth.
• Kippo (svn rev.169) – Kippo is an low-medium interaction SSH honeypot, Also covered
• mitm-ssh – Unsurprisingly, a utility for aiding man in the middle attacks against SSH connections.
• Origami & pdftools – Two frameworks for analysing malicious PDF files.
• Volatility – an excellent memory analysis toolkit
• Zerowine-vm – A malware behavior analysis platform. I’ve covered ZeroWine here before, and whilst I find it useful for initial analysis I found it a pain to setup and get running. The fact this works out of the box on Mercury is enough reason alone to keep the .iso handy.

Other tools are installed on the system as started, access from standard locations (/etc, /usr/bin, etc.). I won’t try to list them all, but some highlights include:

• Nepenthes – Dionaea’s predecessor
• Honeyd – Honeypot system, perfect for emulating multiple different systems from one platform. Covered in more depth here.
• John – John the Ripper, password cracker
• ircd-hybrid – irc server daemon, useful for analysis irc-based malware’s interaction with command and control systems.
• Snort – de-facto intrusion detection system.
• Wireshark – Packet capture and network analysis tools.

I could go on, but I’m sure you get the idea.

Setting up a honeypot, and analysing the results, has never been easier. And I’m sure the toolkit’s functionality will also be useful in other scenarios; incident response, general network administration or as a safe learning platform. So what are you waiting for?

–Andrew Waite

N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at carnivore.it

Running on a Debian 5.0/Lenny server the install was both quick and easy, ‘apt-get install nepenthes’ handles install and dependencies nicely. The only issue I encountered was the permissions of files and directories within /var/log/nepenthes/. The contents had owner and group settings as root:root, as the nepenthes process should (and does under the default init.d script) drop permissions after initialisation this meant that the process was unable write to some of it’s logfiles, reducing the amount and quality of collected information. Thankfully this is easily fixed with a simple ‘chown -R nepenthes:nepenthes /var/log/nepenthes/*’.

I’ve frequently seen complaints/queries on the Nepenthes development mailing list that there are issues with Nepenthes’ hexdump functionality. While it isn’t enabled by default, using this install method works perfectly after uncommenting the “loghexdump.so” line from /etc/nepenthes/nepenthes.conf, depositing collected dumps in /var/lib/nepenthes/hexdumps/.

Initial testing shows the system working nicely (not bad for 30 minutes work) and is beginning to collect new binaries and attack statistics. Next step is some integration with Honeyd to provide the start of a combined honeynet environment, more to come later.

– Andrew Waite

Statistics engine written by Andrew Waite – www.InfoSanity.co.uk

Number of submissions: 4189
Number of unique samples: 1189
Number of unique source IPs: 2024

First sample seen on 2008-05-09
Last sample seen on 2009-10-31
Days running: 540
Average daily submissions: 7

– Andrew Waite

The latest post (dated October 27th 2009) on the Nepenthes site indicates that development on Nepenthes is coming to a close, stating 7 reasons preventing newer features being implemented with Nepenthes. As a result I’m stopping development on my statistics scripts for parsing the Nepenthes’ log files. The good news is that work on Nepenthes’ spiritual successor is well underway, in the form of Dionaea.

I’m hopefully going to get a Dionaea box up and running in the near future to continue were I’ve left off with Nepenthes, watch this space…

– Andrew Waite

an open source (GPL v2) research project to dynamically analyze the behavior of malware. Zero wine just runs the malware using WINE in a safe virtual sandbox (in an isolated environment) collecting information about the APIs called by the program.

The output generated by wine (using the debug environment variable WINEDEBUG) are the API calls used by the malware (and the values used by it, of course). With this information, analyzing malware’s behavior turns out to be very easy.

Install was fairly simple as ZeroWine is distributed as a Qemu virtual image. Qemu, is downloaded here, and ZeroWine here.

To start the ZeroWine image I use the command (change filepaths to suit your install):

>qemu.exe c:\zerowine_vm\zerowine.img -no-kqemu -L . -redir tcp:8000::8000

Once running you can access the service by pointing a browser to localhost/8000 (the ‘-redir tcp:8000::8000′ parameter redirects the ZeroWine image’s port to your local system). This provides a simple web interface to upload and analyse your malware sample:

For a test run I uploaded the most recent sample collected by my Nepenthes honeypot, MD5 hash 3c9563dacd9afe8f2dbbe86d5d0d4c5e. The report generated shows the results of ZeroWines analysis, example below:The first section shows the behavioural analysis of the malware, this should be the most useful aspect of the ZeroWine framework. However as the ZeroWine page itself states, the output is ‘very long and, as so, hard to understand‘ and is unable to distinguish between system calls made by the malware and the underlying analysis framework. As a result I personally find the information provided by the report less useful than it could be.

There are definitely better sources for generating automated analysis of malware samples, for example VirusTotal or CWSandbox. However, depending on how the malware sample was obtained legal or business requirements may prevent you from releasing the sample to a third party, and not all provided services can provide the immediate response of a local system; meaning ZeroWine can still be a valid and useful tool in your arsenal.

Taking the concept forward, Jim Clausing recently released an excellent paper on setting up an automated malware environment with open source tools. I haven’t had a chance to try out any of Jim’s suggestions, but have read the paper and listened to the related podcast and the recommendations are definitely on my todo list to improve my malware analysis toolkit.

– Andrew Waite

The rest of the Super Mondays event was recorded more successfully. Check it out here for the official write-up and event videos. Well worth a look.

– Andrew Waite

Some of the innovative uses for technology on display from Newcastle University provided a great glimpse of where we could be heading in the future towards ubiquitous computing. Of special interest were the research being undertaken with surface computing, which seems to have taken centre stage of new technologies recently, although unfortunately the expected MS Surface device wasn’t available at the last minute.

I also liked the work being done by the Ambient Kitchen project. While the technology is still in it’s early stages it is easy to see how this technology could be a part of every day life. With the focus the group has on providing assistance and support to people with cognitive difficulties the fruits of the project could go a long way to genuinely improving people’s lives. It makes a nice change to see new technology being developed for a real, useful purpose rather than the usual, ‘we can, it’s cool, why not’ approach to some tech development.

Linked with these new technologies Patrick Oliver and Jayne Wallace demo’d and talked about some of their work with developing cultural and meaningful technologies. One example was a twinned pair of necklaces which allowed the wearers to communicate some acts of distance, for example holding one pendant would cause the other to vibrate. As wireless communications become more pervasive I can envision similar technologies becoming more subtle and common place. Despite my initial perception of the topic as being ‘arty’ and not really that useful, I enjoyed the presentation and can see some valid and quite exciting uses for this technology in the future.

The event finished with a change of pace, with me presenting about my experience with using honeypot systems and hopefully convincing others that the system are valid additions to any network, and are good fun in the process. From my perspective I feel that the presentation went well, although I blew through the material a bit rapidly. I was genuinely relieved and thrilled with the amount of questions and discussion that was generated at the end of my presentation.

Unfortunately I believe that there isn’t a recording of this presentation, as is customary with SuperMondays talks, as the video camera decided to flatten it’s battery just before I started. As a compromise I’ve posted my slide-deck from the presentation. Hopefully people may find this useful, I’m always open to questions or discussions so please let me know your thoughts.

Bottom line from all this? SuperMondays is a blast, if you’re in the area and haven’t been along yet, why not? I’m definitely going to make more of an effort to ensure I’m available for future events, see you all there next time.
– Andrew Waite

$ tail -n1 /opt/nepenthes/var/log/logged_submissions
[2009-05-21T19:10:59] 90.130.169.175 -> 195.97.252.143 creceive://90.130.169.175:2526 93715cfc2fbb07c0482c51e02809b937

To start with I wanted to get an idea of what I was dealing with, so I passed the file’s hash to VirusTotal’s Hash Search utility; and promptly found that VirusTotal had no knowledge of this particular hash. Means we could be dealing with a completely new malware strain or variant! or more likely a polymorphic binary creating a unique file signature…

The question was promptly answered when transferring the binary to my analysis machine by AVG, ‘Threat detected: worm/Allaple.b’. Not wanting to take the word of a single AV vendor I proceeded to upload the binary itself to VirusTotal (have I mentioned I like VirusTotal yet?). Sure enough most AV engines agree with AVG’s analysis although there was some dissention over which version of Allaple the sample was. Most AV engines (37/40) flagged file as malicious (Comodo, nProtect and PrevX gave the binary a clean bill of health.)

Beginning with some static analysis, the ‘strings’ utility is always a safe place to start. As I’m using a Windows platform for this analysis I use the SysInternals strings binary. This revealed little, other than confirming the binary is a windows executable (usual ‘!This program cannot be run in DOS mode.’ string) and a reference to Kernal32.dll and some function names (FindFirstVolumeW, GetShortPathNameA, GetConsoleAliasesLengthW, AddConsoleAliasA, GetModuleHandleW, CreateProcessA, GetUserDefaultUILanguage, LocalReAlloc, SetHandleInformation, SetConsoleCursorInfo).

As there was limited information available from a plaintext strings search my next step was to see if the binary had been packed. For this I used PEiD utility, PEiD initially stated that there was ‘Nothing Detected’ although the entropy found within the file (7.93) caused PEiD to suggest that the binary had indeed been packed.

With some basic static analysis undertaken (this could/should have been taken further but my RE/assembly-fu is a bit rusty, especially at 3am) I changed tact and went with some initial behavioural analysis. For an initial run I utilised iDefense’s SysAnalzer tool written by David Zimmer. SysAnalyzer is a great utility for automating behavioural analysis and capturing system changes, from it’s download page:

SysAnalyzer is an automated malcode run time analysis application that monitors various aspects of system and process states.
SysAnalyzer was designed to enable analysts to quickly build a comprehensive report as to the actions a binary takes on a system.

The tool snapshots (not to be confused with VM snapshots) the state of the system, runs a given binary, then snapshots the system after execution before comparing the two snapshots. This can provide some detailed, succinct information to an analyst, but may miss any dynamic and temporary system changes. One weakness (or strength, depending on your perspective) that SysAnalyzer has is that it does not sandbox the malicious binary from the analysis system. Meaning that if the binary is destructive it *will* hose the system it is being analysed on, obviously if you’re utilising virtualisation and snapshop functionality this shouldn’t be an issue.

On starting the analysis, the malicious executable promptly errored (usual Windows’ ‘executable has failed, please send all information to Microsoft’ type pop-up) and SysAnalysis stated that the system was unchanged by the binary. Well that was disappointing, possible some form of VM detection causing the malware to shut down?

Not to be denied, I re-ran the process: Again the executable crashed with Microsoft’s pop-up, but this time SysAnalysis saw some system changes, from API and registry calls to the creation of new processes. However on further analysis the new processes and files were all only related to the DWWIN.exe executable which, as explained here, is part of Windows itself and is the cause of the pop-ups discussed above.

One aspect that may be causing the binary to lock up is that it is isolated from the network. From experience some malware will perform an initial lookup to an external resource, if the code can’t access said resource the malware assumes it is on a closed system and shuts down. To test this theory I re-ran the executable (this time manually, without the SysAnalysis utility) with Wireshark sniffing all network interfaces. As expected the binary crashed with the same error pop-up, reviewing the wireshark capture no traffic was generated outbound to any resource from the infected host.

Another possible reason for malware to refuse to run is newer VM detection techniques. However no evidence of this is present in the API calls captured by SysAnalysis, nor can I find any reference to VM detection capabilities present within the Allaple family from a search of the web. Ideally to test this theory the malware would be executed on a natively installed OS to bypass any potential VM detection. Unfortunately at this stage I do not have resources available to sacrifice a physical machine in this manner, so analysis must stop here.

One final possibility is simply that the binary is defective, just because the malware is spreading does not necessarily mean that the payload delivered upon exploitation is fully functional. It is not uncommon to have one malware strain being propogated by an entirely different strain. This is rapidly becoming more prevelant as ‘cybercrime’ (I hate that phrase) matures with the recent emergence of crimeware-as-a-service.

What-ever the reason for the binary failing to have any perceivable impact on the system, the behaviour that has been observed during this sample’s execution does not match that which is expected from other analysis of the Allaple.b malware strain. Sophos’ analysis for example, states that upon infection Allabple.b will:

• When first run W32/Allaple-B copies itself to [system]\urdvxc.exe.
• The W32/Allaple-B is registered as a COM object.
• W32/Allaple-B installs itself as a service with the name “MSWindows”.

No evidence of this behaviour has been seen during analysis, nor are any of the changes present on the system post infection. This is a good example of why there isn’t always a need to panic when AV picks up a malicious item. Until the infection has been analysed in more depth there is no way of knowing how scary the compromise and infection is.

– Andrew Waite

The session will begin with a demonstration of some new technologies, including ambient kitchens and surface computers. Following this will be a presentation on cultural technology and HCI by Patrick Oliver and a presentation of meaningful technology and her work on digital jewellery by Jayne Wallace, before ending the night with my presentation.

Tickets are free and going fast so register now to reserve your place, event registration.

It is shaping up to be a good night, so look forward to seeing you all there.

– Andrew Waite

This utility is substantially larger than my previous two releases (although still small) so I’ll not include source code here, head to Infosanity for the submissions2stats.py file. Usage is fairly simple, read logged_submissions file into stdin and let the script do it’s job.

Statistics are quite general at this stage, mainly compiling overall statistics from the log file including:

• Total number of submissions
• Number of unique malware samples (based on MD5 hashes)
• Number of unique source IPs
• Run time
• Average daily submissions
• Five most recent submissions

By default the script outputs plaintext to standard out, but this can be changed to HTML via the –output=html commandline flags.

I’m going to hold back releasing any example output from my own servers as I wanted to generate the statistics for use in an upcoming presentation I’m giving for local group Super Mondays. If you’re free and in the area (Newcastle, UK) on May 26th please stop by for the event and to say hi.

If you’re running a Nepenthes server I’d appreciate any feedback or issues running the script. I’m still looking to flesh the system’s capabilities out, so any suggestions/requests for additional features or statistics would be appreciated (contact(no-spam)[at]infosanity[dot]co[dot]uk ).

– Andrew Waite

N.B. The latest versions of all Infosanity tools related to statistic generation for Nepenthes can be found here.