Latest Entries »

A few months ago I read the paper “Technical analysis of client identification mechanisms” [1]. The paper is really interesting and it is really worth investing your time and reading. Just a brief excerpt from the abstract:

“In common use, the term “web tracking” refers to the process of calculating or assigning unique and reasonably stable identifiers to each browser that visits a website. In most cases, this is done for the purpose of correlating future visits from the same person or machine with historical data. Some uses of such tracking techniques are well established and commonplace. For example, they are frequently employed to tell real users from malicious bots, to make it harder for attackers to gain access to compromised accounts, or to store user preferences on a website. In the same vein, the online advertising industry has used cookies as the primary client identification technology since the mid-1990s. Other practices may be less known, may not necessarily map to existing browser controls, and may be impossible or difficult to detect. Many of them – in particular, various methods of client fingerprinting – have garnered concerns from software vendors, standards bodies, and the media.”

A few weeks ago I had a private chat with a dear friend of mine currently involved in the Trackography project [2] and developing his own tool for such purposes [3]. During the conversation, the idea of using Thug for analyzing if a website makes use of some of the techniques described in [1] and to which extent emerged. The idea of using an honeyclient for a so complete different and useful purpose was really exciting for me and so I started thinking about the best way to do it. In order to do it I had to replace httplib2 with requests at first since requests allows me to collect more details about a typical HTTP session. After that I started a new branch (which is still not public) which right now implements just a first single test as shown below.

$ python --web-tracking
[2015-01-27 11:39:36] [MongoDB] Analysis ID: 54c76ae8d637083631c9a7ea
[2015-01-27 11:39:36] [window open redirection] about:blank ->
[2015-01-27 11:39:37] [PRIVACY] Cookie expiring at 2017-01-26 11:39:37 (more than 365 days from now)

Right now it’s not that useful but it will be once all the metrics will be implemented. Stay tuned because Thug is turning to be an honeyclient with steroids in the next weeks!

[1] Technical analysis of client identification mechanisms
[2] Trackography project
[3] Trackmap

Thug 0.6 released!

Thug 0.6 was released just a few hours ago. The most important change introduced during the 0.5 branch was a complete redesign of the logging infrastructure which is now completely modular. This makes adding (or removing) new logging modules extremely easy.

I did this change for a couple of reasons. The first one is that the logging code before Thug 0.5 was developed without a proper design but just adding the modules as soon as I needed them. I usually hate this approach so it would be enough to justify a complete redesign. But there was one more reason. I was aware that a few persons out there were implementing their own logging modules and binding them in some really awful ways to the main code (someone said plugins?). I spent a lot of time in documenting such changes. For these reason I will not dive into details in this post. But trust me. Extending Thug logging with your own modules should be an easy task now. Hopefully. Let me add that additional logging modules would be really appreciated so if you think your cool module should be included in the source tree please feel free to contact me.

Moreover I worked a lot in order to improve the reliability and the performances of the analyses. Sometimes this required just little changes, sometimes not. But I am really satisfied about such changes and the improvements they produced.

I have great plans for the 0.6 branch. First of all I will continue focusing on reliability and performance improvements (probably I never stopped doing it from the first release). Moreover I would love working on the distributed analysis approach which we started experimenting during the Google Summer of Code 2013 and on the client tracking mechanisms detection.

Stay tuned because I just started having fun!

In this post I will analyze the Android APK files that my friend Pietro Delsante from the Honeynet Project Sysenter Chapter talks about in his previous post (thank you Pietro). The files are all named “video.apk” and these are the MD5 and SHA256 hashes:

video.apk 10859e82697955eb2561822e14460463 a36ecd528ecd80dadf3b4c47952aede7df3144eb9d2f5ba1d3771d6be2261b62

video.apk 91f302fd7c2d1b8fb54248ea128d19e0 8e0a2f6b7101e8caa61a59af4fdfc5b5629b8eac3a9aafcc1d0c8e56b4ddad15

video.apk f6ad9ced69913916038f5bb94433848d 4c7c0bd7ed69614cb58908d6a28d2aa5eeaac2ad6d03cbcad1a9d01f28a14ab9

The three APKs are almost identical: they share the same certificate and much more (I will cover the differences later). I started by having a look at the first sample 10859e82697955eb2561822e14460463, this is the content of the AndroidManifest.xml file:


As you can see there are the following permissions (details from the official Android documentation):

  • android.permission.SEND_SMS, which allows the app to send SMS messages;
  • android.permission.INTERNET, which allows the app to open network sockets;
  • android.permission.RECEIVE_SMS, which allows the app to monitor incoming SMS messages, to record or perform processing on them;
  • android.permission.READ_PHONE_STATE, which allows read only access to phone state.

This is consistent with the name that the main antivirus vendors use for this kind of malware (from VirusTotal [1][2][3]):


Having a look at the application code we see that it is split into two parts:

  • version.eleven.MainActivity is the class that is run when the application is started from the Android launcher;
  • version.eleven.SmsReciver (sic) is a subclass of BroadcastReceiver, i.e. it runs when there are incoming SMS messages.

This is the full structure of the APK after decoding it with apktool:

apktool tree

There are some resources that look promising, such as the html hierarchy inside “/assets” and the file “/res/raw/settings.json”, whereas the files inside “/res/values/*.xml” do not yield anything interesting. The app name is Еро Видео (Russian for “Ero Video”) and we also have a pretty windows-like icon:


Looks promising, we are dealing with an app that masks itself as a porn video. But poor Pietro wasn’t looking for some porn, he was headed to the theater to see a show with friends! :-P

At this point before analyzing the code I chose to let the app manually run in a sandbox, to check whether it was a real video or not to test what is presented to the user, which kind of network traffic it generates, what SMS messages are sent, etc. The following is a slightly NSFW video of the execution of the app:


As a side note, there also seems to be some debug-like output on the ADB logcat:



Time to have a look at the code… it has been decoded with a mixture of apktool/dex2jar/jad and then source code has been slightly fixed using manual bytecode inspection. What follows is the MainActivity that is executed when the app is launched. While an overlay progress dialog is shown, in the background are loaded some settings. Then a WebView, which simply stated is a web browser, is started as the application content view i.e. what the user sees; it also has a JavaScript interface called “webapi” set up by the method “addJavascriptInterface()“. The WebView is opened on the URL of the asset page “/assets/html/index.html”, and as soon as the page loads the overlayed progress dialog is hidden and some JavaScript code is executed with the Android version as a parameter.


The calls to “Settings.load()” and “.save()” get and put some data (first, sentSms, time) from the Android shared preferences storage:


Here’s an example of the settings that might be saved inside “/data/data/version.eleven/shared_prefs/settings.xml”:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<boolean name="first" value="false" />
<long name="time" value="0" />
<boolean name="sentSms" value="false" />


The method “MainActivity.loadSettings()” loads instead the file “/res/raw/settings.json” with “Functions.loadAndDecode()” and checks its content against the International Mobile Subscriber Identity (IMSI) retrieved through “Functions.getImsi()”.



The IMSI is a 15-digit number associated with all cellular networks used to identify a single user of the network. Its first five or six digits are the concatenation of the Mobile Country Code (MCC) and the Mobile Network Code (MNC). The MCC+MNC tuple is used to uniquely fingerprint a mobile phone operator and its country of operation. Here we are dealing with a dictionary of operators (op*) and, for every operator, one or more MCC+MNC (codes) along with some number+text (items).


The “settings.json” file contains operators (sometimes MCC+MNC, sometimes only the MCC) from the following countries: Russian Federation, Ukraine, Lithuania, Azerbaijan, Latvia, Estonia, Armenia, Israel, Austria, Belgium, Bulgaria, Belarus, Switzerland, Cyprus, Czech Republic, Germany, Denmark, Spain, Finland, France, Hong Kong, Croatia, Hungary, Iraq, Jordan, Cambodia, Kuwait, Luxembourg, Montenegro, Macedonia, Malaysia, Netherlands, Norway, Portugal, Qatar, Serbia, Saudi Arabia, Slovenia, Slovakia, Taiwan, Kazakhstan, Poland. This file has some minor differences between the three analyzed APKs.


Now, for what concerns the HTML part, here’s the page source header. When the page is loaded a JS animation starts slideshowing some porn images (pic*.jpg), and in the meantime the Android method “Functions.callJsCallbackAndroidVersion(Build.VERSION.RELEASE)” calls the JavaScript function “androidVersion()” in order to set some kind of flag for Gingerbread devices.



When the user clicks on the blue play button, the JavaScript code “goNext()” is run. First, it hides some part of the HTML page (“#page1″) and shows another (“#page2″); that second part is slightly different between the three APKs, but all of them show a porn-related link (Ваша ссылка), a so-called password (Ваш пароль) and a GO button (Перейти). In addition, “goNext()” runs “sendSms()”, which in turn calls the Android method “WebApi.sendSms()” either directly or through the chain “prompt()”, “onJsPrompt()”, “textToCommand()”.



The function first performs a check in order to be sure that it was run successfully at least one day before, then starts a separate thread that runs “threadOperationRun()”. That function retrieves a “MainActivity.settings.smsList” list of number+text, previously populated using “settings.json”, then sends every message using “Functions.sendSms(number, text)”.


Every number to whom an SMS was sent is also saved into “MainActivity.settings.phoneList”, then the shared_prefs persistent settings’ timestamp is updated. This is a sample of the prefs after some SMS messages have been sent:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<boolean name="first" value="false" />
<long name="time" value="1389222812010" />
<boolean name="sentSms" value="true" />


Lastly, here is the code that runs when there are incoming SMS messages. To keep it short, if the phone number of the sender of the incoming message is in the list “MainActivity.settings.phoneList”, then the message is discarded.



To wrap up, we are dealing with a fake “Ero Video” porn app that sends paid SMS messages at most once a day, hiding any subsequent reply to these messages. It has no background service (and no persistence/self boot), and relies entirely on social engineering, i.e. the user has to open the app and click the play button. Moreover, as you can see in the video, the Android system shows a popup warning when the first SMS is sent, hopefully lowering the click-through rate.

For what concerns the fraud and/or monetization schema, I still need to understand the meaning of the text inside the messages. For example, on hxxp://zona-people[.]com/oferta.php (Russian) at the bottom of the page we can see that the numbers inside “settings.json” are billed 6.5€ / 9$ per SMS, but unfortunately no clue about the meaning of the text. Information and feedback are always welcome, you can find me on Twitter.

Some nights ago I was heading to a local theater with some (non-nerd) friends. We did not recall very well the address, so I brought out my phone (LG Nexus 4 with Android 4.4.2 and Google Chrome) and googled for it. I found the theater’s official site and started looking for the contact info, when Chrome suddenly opened a popup window pointing me to a Russian web site ( urging me to update my Flash Player. I laughed loudly and showed them to my (again, totally non-nerd) friends saying that the site had been owned. One of them went on and opened the site with her own phone (Samsung Galaxy S Advance with Android 4.4.1 and the default Android WebKit browser). To make a long story short, after a few instants her phone was downloading a file without even asking her for confirmation. So: Chrome on my Nexus 4 was using social engineering to have me click on a link and manually download the file; Android’s WebKit on her Galaxy S Advance was instead downloading the file straight away: interesting! However, we were a bit late and we had to run for the comedy, so I did not even bother to see what the heck she had downloaded, I only made sure she hadn’t opened it. I thought it was just the usual exploit kit trying to infect PCs by serving fake Flash Player updates, seen tons of those. While waiting for the comedy to begin, I quickly submitted the compromised site to three different services, the first three ones that came to my mind: HoneyProxy Client, Wepawet and Unmask Parasites, then turned off my phone and enjoyed the show.

The day after, I decided to spend some minutes analyzing that exploit kit (you know, just in case…). First of all, the compromised site was made with Joomla 1.7, an older release that has a quite long list of security updates in its short history ( and is now deprecated in favor of Joomla 2.5. I wish I had access to that web server’s logs, those would be quite funny!

However, looking at the source code of the compromised pages, I saw that the malicious javascript was injected at the very beginning of the page:



As you can see (even if the image is cropped), the JavaScript is composed by two main IF clauses. The first one checks whether the User-Agent string may indicate a robot, in which case nothing is done; instead, if this looks like a real browser, the code calls a function that creates an iframe pointing to “ /?id=ifrm” and adds it to the page. Then, if the User-Agent string indicates this might be a mobile phone, the second IF clause also tries to use some basic JavaScript functions to trigger a full-page redirection to the same URL, but passing in a different parameter: “/?id=mob”. Uhm, sounds interesting: an exploit kit with some code specific to mobile phones, I had never seen that but maybe it’s only because lately I had been working on other topics.

I reported the breach to the site owners right after finishing the analysis, on December 30 and they answered on December 31 saying they would clean it as soon as possible. This afternoon (January 7) I checked and the site was clean, but tonight it’s compromised again, so it looks like the owners did not patch the vulnerability, and the exploit is probably being spread in a mechanized way and a quick Google search seems to confirm this hypothesis, as the malicious code was injected in more than 82,100 different pages, and those are probably only the ones that did not get compromised since the inject failed and the javascript code is showing up as text instead of being executed:

Well, after that, I looked at the results of the three scans I had ran the night before. To my surprise, there was almost nothing in them:

  1. HoneyProxy Client did show a connection towards “” which was creating an iframe pointing to “” which contained some obfuscated javascript, however no exploit was run or, at least, no interesting file (PE EXE, PDF, SWF or the like) was downloaded;
  2. Wepawet died on me several times while trying to run it, so I gave it up;
  3. Unmask Parasites was tagging the site as suspicious as it had found some javascript code outside the proper <script> tags.

And that was all. So, I decided to run the site through Thug with the default personality (winxpie60) and – man! – that was deceiving! Nothing found. Absolutely nothing. Not even a single tiny call to a .ru domain or anything of the like. The only external site was, which was a legitimate content of the theater’s site.

Fortunately, Thug’s author Angelo “Buffer” Dell’Aera (our Boss, our Leader, our Shining Star) was wise enough to provide his wonderful tool with an awesome set of different personalities: if the exploit kit did not like Internet Explorer 6, maybe I may fool it with a Galaxy S II with Google Chrome 18 and Android 4.0.3, since it was checking for mobile phones. Guess what, that did the trick! This time, after a few seconds, Thug got redirected to ““, which in turn pointed to ““, then to “” and ““, from which three different APKs were downloaded.

For those interested, this is a small excerpt of Thug’s JSON logs:

“connections”: [
“source”: “hxxp:// www.[compromised_site].com /”,
“destination”: “hxxp:// /?id=mob”,
“flags”: {},
“method”: “href”
“source”: “hxxp:// www.[compromised_site].com /”,
“destination”: “hxxp:// /?id=mob”,
“flags”: {},
“method”: “window open”
“source”: “hxxp:// /?id=mob”,
“destination”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9/”,
“flags”: {},
“method”: “meta”
“source”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9/”,
“destination”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9%2F”,
“flags”: {},
“method”: “http-redirect”
“source”: “hxxp:// /tmpsrc/d586495364701f9ec770e3b9df2df318/video.apk”,
“destination”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9/”,
“flags”: {},
“method”: “window open”
“source”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9/”,
“destination”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9%2F”,
“flags”: {},
“method”: “http-redirect”
“source”: “hxxp:// /tmpsrc/d586495364701f9ec770e3b9df2df318/video.apk”,
“destination”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9″,
“flags”: {},
“method”: “href”
“source”: “hxxp:// /tmpsrc/d586495364701f9ec770e3b9df2df318/video.apk”,
“destination”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9″,
“flags”: {},
“method”: “window open”
“source”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9″,
“destination”: “hxxp:// /lpadultbill/d.php?id=u7be70c982f0a1226ae890bc4d7e3dfe9″,
“flags”: {},
“method”: “http-redirect”

The same result could be achieved by selecting the iPad personality (ipadsafari7) or any other Android one (galaxy2chrome18, galaxy2chrome25, galaxy2chrome29), so it looks like the Exploit Kit is not really making any difference between the actual operating system run by your phone, it’s always serving you an Android app.

The three APK files are actually the same app, with three different small changes in their configuration to talk to three different Command&Control servers, but we’ll talk about this in a later post. For now, we’ll only say they’re all three named “video.apk” and that their MD5 sums are 10859e82697955eb2561822e14460463, 91f302fd7c2d1b8fb54248ea128d19e0 and f6ad9ced69913916038f5bb94433848d.

To sum up things, in this post we’ve seen about a peculiar Exploit Kit that’s being actively spread by some mechanized mean and has already compromised several thousands sites. The exploit kit is behaving in a quite peculiar way as it seems to have been designed with special attention to mobile users (that are currently the only ones that get infected by it), and it’s distributing some malicious APKs that are (more or less) well recognized by AV vendors on VirusTotal (23/47). Last but not least, Angelo “Buffer” Dell’Aera confirmed that it’s the first time he’s seen APKs being distributed that way by an exploit kit, and – to his pride – Thug is able to get them all!

Stay tuned for some further analysis of those APKs by my friend and fellow Sysenter Chapter contributor Andrea De Pasquale!

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!

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/ 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/


34 class ThugPlugins:
35     phases = {
36                         PRE_ANALYSIS_PLUGINS : ‘ThugPluginsPre’,
37                         POST_ANALYSIS_PLUGINS : ‘ThugPluginsPost’
38                       }
40     def __init__(self, phase, thug):
41         self.phase = phase
42         self.thug = thug
43         self.__init_config()
45     def __init_config(self):
46         self.plugins = set()
47         config = ConfigParser.ConfigParser()
49         conf_file = os.path.join(os.path.dirname(os.path.abspath(__file__)), ‘plugins.conf’)
52         plugins = config.get(self.phases[self.phase], ‘plugins’)
53         for plugin in plugins.split(‘,’):
54             self.plugins.add(plugin.strip())
56     def __call__(self):
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)
66             handler = getattr(module, “Handler”, None)
67             if handler:
68                 p = handler()
69             try:
70                 verifyObject(IPlugin, p)
71       , log)
72             except BrokenImplementation as e:
73                 log.warning(“[%s] %s” % (source, e, ))


and src/Plugins/plugins.conf


1 [ThugPluginsPre]
2 plugins: Plugins.TestPlugin
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
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
23 class Handler:
24     zope.interface.implements(IPlugin)
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!

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!

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

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.


Christian Seifert
Chief Communications Officer
The Honeynet Project

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

So what about calling it just Zeus 2.1 ?

Bad Behavior has blocked 910 access attempts in the last 7 days.