peepdf is a Python tool to explore PDF files in order to find out if the file can be harmful or not. The aim of this tool is to provide all the necessary components that a security researcher could need in a PDF analysis without using 3 or 4 tools to make all the tasks. With peepdf it’s possible to see all the objects in the document showing the suspicious elements, supports the most used filters and encodings, it can parse different versions of a file, object streams and encrypted files. With the installation of PyV8 and Pylibemu it provides Javascript and shellcode analysis wrappers too. Apart of this it is able to create new PDF files, modify existing ones and obfuscate them.

We are happy to announce the immediate availability of mitmproxy 0.16! As a major new feature, Thomas Kriechbaumer – who joined us as a Google Summer of Code (GSoC) Student last year – contributed a brand new HTTP/2 implementation built on top of hyper-h2. HTTP/2 requests now blend into the mitmproxy UI just like regular HTTP 1 requests, making mitmproxy the first interactive HTTPS proxy with HTTP/2 support! All HTTP/2 features from RFC7540 are supported - including PUSH_PROMISE, RST_STREAM, and as many concurrent streams as you want. We are super excited about the improvements Thomas is bringing us here and we encourage you to try them out. To make a transition as seamless as possible, HTTP/2 needs to be enabled manually for now by passing --http2 to mitmproxy. We plan to remove this requirement with one of the next releases. For a full list of changes, take a look at the changelog posted below!

One of the very first Android malwares, Geinimi has been analyzed in the application sandbox DroidBox that is currently being developed. The project is part of GSoC 2011 in collaboration with Honeynet and as a master thesis. The Geinimi application uses DES encryption, and it’s possible to uncrypt statically the content, see picture below.

But it’s very easy to do that because the key is not well hidden, so an approach by using dynamic analysis will be more interesting with complex samples. This first real-world sample analysis was carried out to specifically test the crypto API logging.

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.

Today, Steven Adair from Shadowserver imformed us about a new piece of malware that looks like a new version of the infamous Storm Worm. Storm was one of the first serious peer-to-peer botnets, it was sending out spam for more than two years until its decline in late 2008. Mark Schloesser, Tillmann Werner, Georg Wicherski, and I [Stormfucker](http://www.h-online.com/security/news/item/Storm-Worm-botnet-cracked-wide-open-739607.html> did some work on how to take down Storm back then, so the rumors about a new version caught our interest. Mark, Tillmann, and me started to take the sample apart, and it looks very much like Storm indeed. It even uses the same configuration file, stored under C:\WINDOWS\herjek.config (the same filename as used by the last Storm version), but as the command-and-control channel has been replaced with an HTTP based version, there is no peer list included anymore. When we looked at it, just contained two lines:

While it seems to be impossible to say whether waledac is the successor of storm or not, what we can do is take a look at the traffic encryption. They guys over at Shadowserver have already blogged some details about this. We at the Giraffe Chapter investigated waledac’s communication protocol further. Here are our results.

Waledac uses regular HTTP request to transmit command requests and to retrieve responses. It uses HTTP fast-flux proxies to hide the true origin of the command&control (C&C) server. Due to the fact that the regular Windows HTTP API (WinINet) is used, the traffic is hard to differentiate from regular HTTP traffic. Furthermore, it even allows Waledac to use proxy servers after the user has generally authenticated. The requests use POST and encrypted + encoded payload data:

Waledac is wishing merry christmas

There is a new bot in town. It’s called Waledac. The way it is spreading reminds a lot of people of the good old storm botnet: An email is sent containing a “christmas card” in form of the executable “postcard.exe”.

A preliminary view on the binary has been given by the Shadowserver guys (Steve Adair).

I had the chance to have a first look at the binary (MD5 ccddda141a19d693ad9cb206f2ae0de9) and want to note down some of my few findings to let the hunt begin.

As libemu had it’s second release (0.2.0) lately, I’ll try to introduce it to the audience who did not hear about it yet.

libemu is a small library written in c offering basic x86 emulation and shellcode detection using GetPC heuristics. Intended use is within network intrusion/prevention detections and honeypots.

This post is split into four parts:

• Practical libemu usecase, showing how it executes shellcode and which information we get from it
• Explanation of libemu and how it detects shellcode
• High level shellcode profiling and pre-requirements for this step
• API call hooking internals

Example

the input shellcode

The shellcode was created using metasploit 3, it is a windows bindshell decrypted with a xor chain. ./msfpayload windows/shell_bind_tcp R | ./msfencode -e x86/countdown -t raw > msf_windows_shell_bind_tcp_countdown.bin In order to provide more realistic conditions, we added a 4k bytes long head as well as a 4k bytes long tail using random data. dd if=/dev/urandom of=4khead.bin count=4 ibs=1024 dd if=/dev/urandom of=4ktail.bin count=4 ibs=1024 And concatted the head, the shellcode, and the tail to our testing buffer. cat 4khead.bin msf_windows_shell_bind_tcp_countdown.bin 4ktail.bin > the_test_shellcode.bin