Latest Entries »

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 ?

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
RETN 0x8

And this is how the hooked syscall looks like

MOV EAX,0xce
MOV EDX,0x00152958 // pointer to fake KiFastSystemCall
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).

– “it bypasses DEP and ASLR using impressive tricks and unusual methods” – Vupen

– “it uses a previously unpublished technique to bypass ASLR” – Metasploit Blog

- “exploit uses the ROP technique to bypass the ASLR and DEP” – ZDnet/Kasperky

– “it’s so scary I ran away screaming” – anonymous

Is that PDF so scary? I don’t think so.

DEP is an hardware feature that prevents execution of data, it obviously works if software sets the execution flag only on memory pages containing code.

If you VirtualAlloc all of your memory with PAGE_EXECUTE_READWRITE DEP can’t help.
If you opt-out, it can’t help.
If you disable it system-wide.. guess what.

Is “directly executing injected data” the only way to get “arbitrary code execution”? Answer is: nope.

It is possible to get “arbitrary code execution” by taking advantage of the call/return mechanism of x86. This was called ret2libc more than ten years ago and it works by injecting fake stack frames instead of code. The return addresses of those stack frames are used to jump to code already in memory that belongs to main executable or libraries. By chaining stack frames, if enough functions are present in memory, you can achieve “arbitrary code execution”.

Since windows is pretty happy to give you memory with write and execution permissions and there are even a few api to programmatically disable DEP, there’s no really need to use ret2libc to implement the entire shellcode. Instead you use it to call just a couple of functions or “pieces of functions”(gadgets) to ask for +RWX memory, copy the shellcode there, jump to it. All you need is the addresses of those functions/gadgets.

Is that a DEP bypass? nope. but it’s smart and convenient, isn’t it?
Is it something new, at least in the wild? nope.
ret2what? ret2libc, but cool guys now call it ROP.

ASLR is a software feature that randomizes memory allocations and should stop ret2libc because it makes hard to guess the location of a piece of code. It works if software does not give the attacker too much control over memory allocations.

If software does leak pointers ASLR can’t help.
If you don’t opt-in, it can’t help.

How that scary exploit works? It uses heap-spray to fill the memory with fake stack frames and ret2libc to “bypass” DEP as describe above, the addresses of functions/gadgets used to put the shellcode in an +rwx area come from a DLL that does not opt-in to ASLR.

Is that an ASLR bypass? nope, it’s sounds to me like bypassing ASLR when ASLR is disabled.

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