Thug: 1000 commits, 1000 thanks

Two years are passed from the first commit and taking a look at the number of committed patches I realized that right now the patch number 1000 was committed. Let me say it’s really impressive realizing it. In the last two years I had a lot of fun thinking and designing the future of this project and I’m really proud of what Thug turned to be. I have to thank a lot of persons who contributed with their suggestions, ideas, bug reports and sometimes patches. You know who you are. Really thanks! Stay tuned because I’m already moving towards patch number 2000 with a lot of new features and ideas like the Thug Honeyclient Distributed Task Queing.

Thug provides a DOM implementation which is (almost) compliant with W3C DOM Core, HTML, Events, Views and Style specifications (Level 1, 2 and partially 3). It makes use of the Google V8 Javascript engine wrapped through PyV8 in order to analyze malicious Javascript code and of the Libemu library wrapped through Pylibemu in order to detect and emulate shellcodes.

Currently 8 Internet Explorer (Windows XP, Windows 2000, Windows 7), 6 Chrome (Windows XP, Windows 7, MacOS X, Android 4.0.3, Linux), 3 Firefox (Windows XP, Windows 7, Linux) and 3 Safari (Windows XP, Windows 7, MacOS X) personalities are emulated and about 90 vulnerability modules (ActiveX controls, core browser functionalities, browser plugins) are provided.

The source code is available here.

Have fun!

Posted in News

Thug Plugin Framework

In the last months I spent a lot of efforts in Thug development. During these months a few interesting features and improvements were introduced but right now I want to spend some time for taking a look at the new plugin framework introduced in the version 0.3.0. If you ever thought about extending Thug with additional features but didn’t know how to do it you should really keep on reading. Let’s start by taking a look a the code.

Taking a look at src/thug.py we can now read these lines of code

 

216 if p:
217     ThugPlugins(PRE_ANALYSIS_PLUGINS, self)()
218     p(args[0])
219     ThugPlugins(POST_ANALYSIS_PLUGINS, self)()

 

Please note that every operation done by Thug is started by line 218 but now you can see that two hooks exist in order to execute plugins in a pre and post-analysis stage. Let’s keep exploring the source code and let’s take a look at src/Plugins/ThugPlugins.py

 

34 class ThugPlugins:
35     phases = {
36                         PRE_ANALYSIS_PLUGINS : ‘ThugPluginsPre’,
37                         POST_ANALYSIS_PLUGINS : ‘ThugPluginsPost’
38                       }
39
40     def __init__(self, phase, thug):
41         self.phase = phase
42         self.thug = thug
43         self.__init_config()
44
45     def __init_config(self):
46         self.plugins = set()
47         config = ConfigParser.ConfigParser()
48
49         conf_file = os.path.join(os.path.dirname(os.path.abspath(__file__)), ‘plugins.conf’)
50         config.read(conf_file)
51
52         plugins = config.get(self.phases[self.phase], ‘plugins’)
53         for plugin in plugins.split(‘,’):
54             self.plugins.add(plugin.strip())
55
56     def __call__(self):
57         self.run()
58
59     def run(self):
60         for source in self.plugins:
61             module = __import__(source)
62             components = source.split(‘.’)
63             for component in components[1:]:
64                 module = getattr(module, component)
65
66             handler = getattr(module, “Handler”, None)
67             if handler:
68                 p = handler()
69             try:
70                 verifyObject(IPlugin, p)
71                 p.run(self.thug, log)
72             except BrokenImplementation as e:
73                 log.warning(“[%s] %s” % (source, e, ))

 

and src/Plugins/plugins.conf

 

1 [ThugPluginsPre]
2 plugins: Plugins.TestPlugin
3
4 [ThugPluginsPost]
5 plugins: Plugins.TestPlugin

 

The configuration file plugins.conf defines which plugins are to be loaded in pre and post-analysis stage (you can specify many plugins by simply comma separating them). The plugins should contain a class named Handler which should be conform to this interface

 

21 class IPlugin(zope.interface.Interface):
22     def run(thug, log):
23     “””
24     This method is called when the plugin is invoked
25
26     Parameters:
27     @thug: Thug class main instance
28     @log: Thug root logger
29     “””

 

If the interface is correctly implemented the `run’ method is called with two parameters: the Thug class main instance and the Thug root logger. Let’s see a really simple example of plugin

 

20 import zope.interface
21 from .IPlugin import IPlugin
22
23 class Handler:
24     zope.interface.implements(IPlugin)
25
26     def run(self, thug, log):
27         log.debug(thug)
28         log.debug(log)

 

This plugin just logs the parameters but you can do whatever you want. Do you want to pre-check if the URL domain is within a blacklist? Just do it with a pre-analysis plugin. Do you want to extract and/or correlate information from the MAEC log files? Just do it with a post-analysis plugin. Simply staten… have fun!

Posted in Honeynet Project, Projects, Thug

Low-interaction honeyclient Thug released!

I’m glad to announce I publicly released a brand new low-interaction honeyclient I’m working on from a few months now. The project name is Thug and it was publicly presented during the Honeynet Project Security Workshop in Facebook HQ in Menlo Park. Please take a look at the presentation for details about Thug.

Just a few highlights about Thug:

  • DOM (almost) compliant with W3C DOM Core and HTML specifications (Level 1, 2 and partially 3) and partially compliant with W3C DOM Events and Style specifications
  • Google V8 Javascript engine wrapped through PyV8
  • Vulnerability modules (ActiveX controls, core browser functionalities, browser plugins)
  • Currently 6 IE personalities supported
  • Hybrid static/dynamic analysis
  • MITRE MAEC native logging format
  • HPFeeds and MongoDB logging

The source code is available here.

Feedback and comments welcome.

Have fun!

Posted in Honeynet Project, Projects, Thug | Tagged , ,

Forensic Challenge 8 – “Malware Reverse Engineering”

I am pleased to announce the next forensic challenge: Forensic Challenge 8 – “Malware Reverse Engineering”.

The challenge has been created by Angelo Dell’Aera and Guido Landi from the Sysenter Honeynet Project Chapter.

Submission deadline is June 15th and we will be announcing winners around the third week of July. We have a few small prizes for the top three submissions.

Have fun!

Angelo Dell’Aera
The Honeynet Project

Posted in News | Tagged , , ,

Forensic Challenge 2010/6 – Analyzing Malicious Portable Destructive Files is now live

Another challenge is ready to be tackled by forensic analysts, students, hackers and alike. This time, we present you with an attack vector that has become quite successful: malicious PDF files!

For challenge 6 of our series (provided by Mahmud Ab Rahman and Ahmad Azizan Idris from the Malaysia Honeynet Project Chapter) we present you with a pcap file that contains network traffic generated by the following scenario: An unsuspecting user opens a compromised web page, which redirects the user’s web browser to a URL of a malicious PDF file. As the PDF plug-in of the browser opens the PDF, the unpatched version of Adobe Acrobat Reader is exploited and, as a result, downloads and silently installs malware on the user’s machine.

We prepared a set of questions that requires you to dive deep into the portable document format. Submit your solution by November 30th 2010. The top three submissions will receive small prizes.

Enjoy!

Christian Seifert
Chief Communications Officer
The Honeynet Project

Posted in Honeynet Project, News | Tagged ,

Murofet, Zeus++ or just Zeus 2.1?

The first one writing about this new threat was Marco Giuliani. So, Murofet or Zeus++?

Taking a look at a couple of samples we were able to identify:

– Same API hooks
– Same encryption routine for configuration file (RC4)
– Pretty much the same configuration file format

Here you can take a look at a decrypted configuration file. It’s possible to realize that it makes use of the same block-based structure of Zeus configuration files. Just like any other Zeus it has a block with id 0x214e (at offset 0x1c) where the version of the builder used to create the bot is stored (at offset 0x2c). In our case that is 2.1.0.7.

So what about calling it just Zeus 2.1 ?

Posted in News | Tagged , ,

Trojan Carberp

I’m interested in infostealers and specifically in banking-trojans so I didn’t want to miss this one. Samples of Carberp are floating around at least since last spring but in late September we saw such numbers increasing.

Taking a look at how Carberp hooks API it looks like yet another Zeus “clone”. What I found interesting is how it hooks system calls. This is how a normal syscall looks like

MOV EAX,0xce // ZwResumeThread syscall id
MOV EDX,0x7FFE0300 // pointer to KiFastSystemCall
CALL DWORD PTR DS:[EDX]
RETN 0x8

And this is how the hooked syscall looks like

MOV EAX,0xce
MOV EDX,0x00152958 // pointer to fake KiFastSystemCall
CALL DWORD PTR DS:[EDX]
RETN 0x8

Instead of overwriting the first instruction(s) with a JMP/CALL to redirect the execution flow to the hook, Carberp substitutes the pointer to KiFastSystemCall. This is nothing new but it is actually enough to hide such hook from most of the “anti-rootkit” products out there (including rkunhooker).

Posted in News | Tagged