I was contacted a few days ago by a person who had knowledge of a small Electronik Tribulation Army botnet.  You might remember these guys as being GhostExodus’ old group.  The contact sent me the source code of a PHP bot that connects to an IRC command & control.  The source was was obfuscated using the Free Online PHP Obfuscator.  To find the C&C server, I went through a process of stripping away the obfuscator’s layers of encoding, which I’m documenting here.  This information might be useful if you’re doing similar reverse-engineering work on this PHP obfuscator (or others).

Note: At each stage, I have stripped the “<?php” tags to prevent the code from running accidentally.  If you are following along, you’ll need to re-insert them (and preferably do so within a sandbox environment).

Stage 1

Here’s the original chunk of code:

On the first line, a variable is being set to a string that’s being represented by a mix of hexadecimal (‘\x’) and octal (‘\’) escape sequences.  This obfuscator makes extensive use of this technique. Python uses the same escapes as PHP for hex and octal, so it’s easy to use my always-open python shell to see a “normalized” ascii representation of these strings:

>>> "\x62\141\x73\145\x36\64\x5f\144\x65\143\x6f\144\x65"

PHP allows strings to be used as function names with a very easy syntax, so the variable $v539ded4bc2c gets set to “base64_decode”, which is then called with a large string of base64-encoded code.  The decoded string of code then gets passed to eval() to execute.  We’d rather just see what the decoded string is, so the easiest thing to do is replace the eval() with a print().  Then we can dump out the next stage:

hacbooknano:php_reverse wesley$ php original_print.txt > stage2_1.txt

Stage 2

Here’s what we have now:

The lack of line breaks is annoying, so a little dirty python code to split that up:

import sys

fp = open(sys.argv[1])
data =

for i in data:
   if i == ';':

Running this:

hacbooknano:php_reverse wesley$ ./ stage2_1.txt > stage2_2_linebreaks.txt

We now have this:

The first 133 lines set up obfuscated names for the rest of the code in this stage. It builds them a character at a time, interleaving them.

We can decode these names by copying those assignments out to another file, and printing the obfuscated names out at the end:

hacbooknano:php_reverse wesley$ php stage2_3_displaynames.txt
x24b0884a06dee76da986eb65ba2940d = base64_decode
t104a34fab793aa8acc27101aa69e16d = ereg_replace
f28748ed1b08d4ce5faba4c5bbe478a2 = file_get_contents
sba02b7a6e9217c818bda90209467b6b = gzinflate
k9c9e40dc7cf4574c577417cdc8ae8a4 = md5
fafd3e80e124e1f5d45522b2e31e3eab = ob_end_clean
n8ad08ea0791139ed748c49d82092979 = ob_end_flush
v077b05ec0999fba76a979f188a32e32 = ob_get_contents
gb6e4eb13daf014a331ffe0376f2357b = ob_start
ff29e8f9567141dfd9b4c31c83a38d63 = str_replace
gb4ceeb3708efd3539d845de0b7fd52e = str_rot13
g52eba32e62d0a481f8e5efd196b27b8 = strpos
n8af683210c35ad36253a33d28a3fbde = strtok

Now, you can take this and go back to stage2_2_linebreaks to rename all the functions to their more readable names.  I did this manually with search-and-replace in TextMate, since I wanted to see what was being replaced and when.  I also normalized the strings as I did in stage 1.  You wind up with the following code:

There’s what appears to be a tamper check, though I didn’t really play with it much since there’s no reason to.  All we’re interested in at this point is the body of that “if” clause.  A chunk of encoded text is ROT-13′d, base64 decoded, gunzipped, and finally eval()’d.  If we chop out the tamper check, and replace the eval() with a print() again, we get to move on.

Stage 3

Here’s what we have now:

This is close to the original code.  The obfuscator has encoded the strings, done away with whitespace, and randomized variable names.  We can normalize the strings, as above, and reformat the code.  For variable names, that’s where we have to do some more human-eyes analysis.  By looking at what the variables are set to, what functions they are being passed into, and other contextual information, we can give most variables much more reader-friendly names.

I only partially went through this process with this file, as I found what I needed, and had a good idea of the rest of the file.  The partial cleanup is here:

Here’s where it’s assigns the botnet C&C server settings:

$filename = "./a73v9.php";
$current_dir = "./";
$channel = "#nobotshere";
$host = "";
$port = 65000;

The system, at the time, had been compromised by the ETA member, MR^E, giving shoutouts to the other ETA members:

(Real smart, defacing your own botnet C&C)


I’d like to thank my twitter followers for being very rapid in getting back-channels in-gear to get the C&C hosting and domain taken out.  While they’re back to much more typical skiddie activities (as opposed to backdooring hospital HVAC systems), it’s obvious that these guys haven’t learned much of a lesson.  One can only hope that one day they’ll realize that they can build on the skills they’re using to run nets like this to get a start in legitimate security work, before it’s too late and they manage to burn their bridges and/or get busted.

Hopefully this will help some folk get a start in reversing PHP (and other interpreted language) de-obfuscation as well.  It’s pretty easy, and I think that files like this would serve as a good introduction for students to the concepts involved in reverse engineering in general.  After a few baby-steps like this we can move them up to compiled code :) .

Update: Looks like the original author of the bot code found out about this post, and decided to post the original source, along with a rant about how I “pick on retards”:


Shawn Moyer and Nathan Hamiel’s talk at Defcon 17, Weaponizing the Web: More Attacks on User-Generated Content, is now available on Vimeo:

Shawn Moyer and Nathan Hamiel: Weaponizing the Web (DefCon 17) from Vim EeeeOOO on Vimeo.

I just finished watching it (unfortunately missed it while I was in Vegas), and it’s very good.  I’m looking forward to playing with MonkeyFist.


Someone, apparently trying to perform a really anemic denial-of-service or just trying to waste bandwidth, has written a Yahoo! Pipes application to repeatedly grab my front page. It shows up as a request for robots.txt with the user-agent “Yahoo Pipes 2.0″, and is followed by a lot of requests for “/” from hosts matching htproxy[num][num] (,, etc.).

It doesn’t appear to be beefy enough to affect availability, so it’s more of an annoyance than anything.  It’s either someone too frightened to take his or her problems up with me directly, opting instead to hide behind a slow proxy, or it’s simply someone with a tragic bug in their Yahoo Pipes app.  I was willing to give it the benefit of doubt for a couple of days, but the latter possibility seems to be less and less likely as Pipes’ steady march continues.

What’s more, Yahoo Pipes’ abuse email ( listed here bounces. I’ve sent my inquiry along to security@ and pipes-bd@, so hopefully someone there can fill me in more on what’s going on.

In the meantime, I’ve taken steps to block Yahoo Pipes from this site.  We’ll see how well that works.  If you are running a legitimate Pipes app that uses this site (doesn’t seem to be a lot of other Pipes activity in my logs), then this may break it, and you’ll just have to hang tight for a while.

Edit: Looks like a couple of people at yahoo have taken a look at the logs I emailed them.  I guess we’ll see if they write me back :)

Edit: Got a couple of responses.  The requests are coming from the Yahoo Query Language (a sister project of Pipes), and they’re looking into the problem.

Oh Bother Edit Again: Yahoo Query Language (YQL) is all kinds of messed up.  It spoofs a Firefox user agent for most of its requests, making it look like some skiddie tool when it freaks out and runs up over 9000 requests in 3 days.  I’d recommend robots.txt’ing it off, but there is/was/for-how-long-was-it-anyways a bug in it where it incorrectly parses it and goes to town on your site anyway.  That’ll be sorted out by the time you get to this, hopefully.


Over at the excellent site, the results of the Santa Claus is Hacking to Town Skillz Challenge have been posted:

These challenges are a lot of fun, and educational as well.  Ed Skoudis puts a lot of effort into writing and judging them.  There’s a whole archive of previous challenges available here, and I highly recommend at least reading through, if not working through, some of the previous challenges.  

This time around, I managed to get an honorable mention for my entry!  I’m very happy with this.  I was unable to test the Windows-centric parts of my solution before I had to submit it and move on to real work, so that part wasn’t %100, but I did have a really solid way of getting netcat onto the web server via the command-injection-vulnerable script, and some nice netcat pivoting.  

Oh, and apparently I’m a security stud! :

We had entries from notable security studs like Wesley McGrew, Raul Siles, Ryan Linn, Mark Baggett, Zoher Anis, Paul Tartar, and others.

I might put “notable security stud” on some business cards, or maybe a button, now.


Yesterday, I took a lighthearted look at some of the Google searches people have used to arrive at this site.  I saved one of them for today, however, because it was enough fun to warrant its own post.  That search query is:

  • review

Well, I suppose I can give that a try.

What is  It’s a service that promises to hack yahoo, hotmail, rediff, and google Email accounts.  Here’s what their website looks like, if it’s down by the time you read this:

You might remember that I’ve looked at a site similar to this in a previous post.  Here’s how things are supposed to go down, according to their site:

The proof takes the form of screenshots of inboxes, sample emails, contacts, or other personal information.

I decided to see how this would play out, assuming (correctly) that it would work much like the scheme described in a previous post.  So, yesterday I filled out their order form, using my own yahoo email account as a target, from another account that I had created that is posing as someone who doesn’t like me very much:

This morning, in the account I had a “surprise”!  Yay!

“Helo”?  What am I, an SMTP server?  As you might be able to imagine, I don’t know anyone named Jonathan Regon, and certainly not well enough to warrant “Luv and Regards”.  Let’s take a look at the link to the phishing site:

So, obviously the single “?wesleymcgrew” parameter sets the username.  If you punch in anything and Submit, you get forwarded along to a real 123greetings card:


Back to the phishing site, what happens if we take the php filename out of the URL, going straight to the directory?

Neat, no directory protection or index.html/php, but not much of interest.  What if we go up a directory?

Now this looks more interesting.  What’s in Y.txt?

The phishing URL sent to me contained the directory name ending in “1003″.  That corresponds with the “1003″ line in Y.txt with the name “Jonathan Reagan”.  Sounds like the Jonathan “Regon” that emailed me.  These are the names being used in the phishing emails, and  each of the above directories contains links to greeting cards from these names.

The “/Y/” here stands for Yahoo.  There are similar directory structures on this site for “/H/” (Hotmail) and “/R/” (Rediff).  There is no “/G/” for Gmail, surprisingly, and no other single-letter directories (tried them all).

Who is  WHOIS shows all contacts as:

Registrant:, Inc.

    Kajaria, Sharad        (

    1674 Broadway

    Suite 403


    New York,10019


    Tel. +001.9176036425

This is the exact same contact information as on the real, with a different email and phone number.’s WHOIS information is set to its registrant’s ( private registration-by-proxy name and address.

I have fired off an abuse email to’s host,, so it may be down soon. itself appears to be hosted in China, so I don’t hold out much hope for that going down. 

In conclusion:


Every night, Analog generates a summary of this site’s logs from the past seven days, and when I bother to check it, it’s an entertaining read.  My favorite part is the “Search Query Report”, which scrapes through my logs, pulling out the search terms people are using on Google (and other search engines) to get to my site.  I think it’s an interesting form of “pre-viewing feedback”, or, more clearly, a reflection of what people are expecting to see when they click a link to go to my site.

Today, I’ve decided to have a bit of fun, share a few of the funnier/more-interesting recent queries, and respond to them.  After all, it is my place to please my new readers ;) :

  • 0×000000 the hacker webzine dead
    • Is it?  It is down.  That’s a shame, I enjoyed reading the articles there, and hadn’t noticed that my RSS reader hasn’t picked up new posts since September.
  • script kiddies haven
    • That is exactly what you have found here at ;-)
  • personal password management
    • In an early post to this site, I discussed using Pwman3 with a hack I described to make it use pwgen as a password generator.  Nowadays, however, I highly recommend KeePassX.  It works great on OS X, Windows, and Linux.
  • describe ram images
    • Well, I’ll give it a shot:  A RAM image would be a byte-for-byte copy of the contents of RAM at some point in time.  A snapshot in time, if you will.  It’s likely to contain code and data (such as text, images, and even passwords) that were in memory at the time of the image-taking.  You can make one yourself with one of my tools, msramdmp, now that you understand what you are creating.
  • trend micro boycott
  • sans security training rapidshare links, (among other searches for pirated SANS materials)
    • Oooh naughty naughty.  I know it must be expensive to travel to SANS conferences from Saudi Arabia, but perhaps you could do the @Home options.
  • how can i dig up root fs on runescape
  • how to make a runescape phisher
    • I get a lot of search hits from people who are looking for phishing kits. Are these things really that hard to make?  I don’t think so.  A lot of the ones that are out there and available to download also secretly shuffle off the passwords to as well.  Phishers phishing phishers.
  • yousif yalda docs
    • A lot of searches like this.  There’s no shortage of people out there mad at this guy.  If you’re new here, you can have some laughs here, here, and here.

This was fun to put together, so I’ll do it again sometime when I gather up more of these interesting search terms.


After seeing some very “spammy” referral links to a recent post re-exposing an ill-tempered script kiddie, and other interesting traffic in my logs, I noticed that the post in question dropped like a rock off Google search results for terms it should hit on.  Notice here how even searching for the title of the post will turn up links to it, but not the post itself.  I’ve noticed this phenomenon once before on this site, with another post.  Smart and avid readers of this blog probably already have some theories about who’s responsible, and what’s going on ;-)

Edit (Sun Sep  7 12:22:02 CDT 2008): As of this particular moment, the page seems to have reappeared on Google’s search.  Not sure why (glitch in the matrix), or for how long.  I’m going to leave this post up, though, as the topic is still very interesting.

Edit (Thu Sep 11 19:12:31 CDT 2008): Annnd now it’s back down, hard.

I’m definitely no SEO expert, and certainly not anywhere near an expert on the more arcane aspects of negative or blackhat SEO.  I did, however, have a good time reading about a tactic that some call “Google Bowling”.  The term makes it sound like a lot of fun, and I imagine it is–for the people taking part in it.  Here’s some links:

The idea here is: by creating links to a page on sites that are blatantly “spammy” and subject to a very negative weight by a search engine’s ranking algorithms (in this case, Google’s), the ranking of the target page can be dragged down, or, apparently delisted completely.  A little poking around in search results for “Google Bowling” reveals several groups that will do this for you, for a fee.  I doubt that the perpetrator in this case has the resources and skill to pull this off on his own, so I certainly hope it was worth whatever he paid :-) .

This isn’t really the site you want to go for, regarding SEO information, and it’s little more than a curiosity when it happens to isolated posts on a blog, but it’s definitely something you might be interested in when it’s your organization being seriously targeted by a competitor that implements these tactics.  It’s difficult to see it happening, except for an occasional referer from a spam site.  The negative sites linking to you are almost certainly such SEO black holes that you won’t be able to find them reliably using Google.  It’s also difficult to figure out who’s responsible, unless the answer presents itself in the pages that have been “bowled”, as it has in this case.

The only real defense, from what I’ve read, is to minimize the impact of negative links by overwhelming them with positive links.  This is pretty easy for larger sites, and makes the cost of “bowling” pages on those sites quite a bit higher.  Smaller blogs, like this one, that average a few good incoming links per post are much more vulnerable.  In this particular case, I’m grateful to the guys at (the larger-than-this-site), who have kindly mirrored the Yousif Yalda posts on this site in their extremely informative and entertaining Charlatans pages.


Last night, I received a phishing email wanting my university email account information.  Whenever I’m picking through email headers, or any other kind of network forensics, I find it useful to punch the IP addresses I find into Google.  You can often build a good image of what that particular system or network is used for, by reading abuse reports, exposed log files, logs of Wiki edits, and all sorts of other situations where an IP address might be indexed by a search engine.  

This particular bad-guy IP is a great example of an IP address that has really made its mark on Google, so I’ll link the results here:

* Google search results for “″

Off the eastern coast of Madagascar, there’s an island called Mauritius.  On this island there’s the city of Ebene.  In this city, there’s this building, the “Cyber Tower”.  According to Whois, on the third floor of this building, there’s a computer being used for all sorts of phishing and fraud.  

It would be “just another scammer”, but this one has a great sense of humor.  Check out this diff on an edit made from that IP address on the Wikipedia entry for Advance fee fraud:

Very nice.



Update: Check out the comments!  Supposedly it’s patched but I tried it again and it worked.  I probably caught them in the middle of a fix, so it’ll probably be fixed soon, maybe by the time you read this. OK, it’s patched, for-real now!

The post is still worth reading if you’re interested in CSRF vulnerabilities, though.  A friend of mine read it, with no previous knowledge and then found an even better vulnerability in an even bigger app than this in what seemed like minutes. I’m totally jealous.

The quick and dirty: By viewing a page on a completely unrelated site while logged into Twitter, you can be forced to post something to your Twitter that you did not intend to post.


If you have a valid login session with Twitter going right now, click here to make yourself post an inspirational message about me. Nevermind the certificate: the same can be done with a good cert.

This still works, but I’m going to go ahead and post about it for a few reasons:

  1. It’s not easy to figure out where you’re supposed to submit or email security concerns to Twitter. I submitted something to, but I don’t even know if anyone read it.
  2. Regarding (1), if you search Google for: twitter “security contact” right now, it turns out that I’m the first hit.
  3. If someone manages to trick you into posting something to your twitter, it’s bad, but it’s not exactly the end of the world.
  4. It’s fairly easy for you, as a Twitter user, to avoid it.
  5. It’s a good, simple, real-world example of CSRF and might get you thinking about how handle this in your own applications.

For those of you who are new to the concept, Cross-Site Request Forgery (CSRF) is an attack where a page on one site causes the user’s browser to submit a request to another site. If the browser has a valid cookie for a logged-in session on the target site, then requests can be made to do very bad things. It’s easy to make cross-site GET requests: just put your URL with the parameters you want to send into an img tag. It’s only slightly less trivial to do the same with POSTs, which requires a little bit of javascript.

One good way to protect against CSRF attacks is to have an unpredictable, generated token as a hidden value in each form presented to the user, and to check that token when the form is submitted. If the page that is submitting a request to the other site can’t guess what the token is, then the request fails. If you look at the Twitter interface’s update form, it looks like they implement this kind of protection:

<form action="/account/update_send_via" id="send_via_form"
 method="post" onsubmit="new Ajax.Request('/account/update_send_via',
{asynchronous:true, evalScripts:true, 
parameters:Form.serialize(this) + '&authenticity_token='
+ encodeURIComponent('0e7c1206546db5df229099cf9e8a7cb503d25cab')});
return false;"><div style="margin:0;padding:0"><input
name="authenticity_token" type="hidden"
value="0e7c1206546db5df229099cf9e8a7cb503d25cab" /></div>
               <input checked="checked"
               type="radio" value="im" />
       <label for="current_user_send_via_im">im</label><br /> 

<input id="current_user_send_via_none"
       onclick="$('send_via_form').onsubmit()" type="radio"
       value="none" />
       <label for="current_user_send_via_none">web-only</label>

I actually didn’t even try to CSRF the above. There’s an “authenticity_token” input, which looks to be the token I mentioned above. It’s all very complicated looking, and I didn’t feel like bothering with it when I knew what I really ought to be looking at: the mobile interface.

Twitter’s mobile interface, which you can switch to at the bottom of your Twitter page, has a much simpler form for updating:

<form action="/status/update" method="post">
<input type="hidden" name="source" value="mobile" />
<input type="text" name="status" id="status" 
maxlength="140" class="i" value=""/>
<input type="submit" value="update" class="b"/>

Much easier. I whipped up this test HTML and put it on my web space:

function post_form()
<body onLoad='post_form()'>
<form action='' 
name='twitform' method='POST'>
<input type='hidden' name='source' value='mobile'>
<input type='hidden' name='status' value="I truly believe 
@McGrewSecurity to be the nicest guy I've ever known.">

Then, I navigated to it, and was surprised to see…

Bad news and good news for the attacker. Bad news: it checks the referrer. Good news: it comes right out and tells us what we need to do. There are a few situations where HTTP_REFERER is suppressed. The easiest way we can make this happen is by hosting the code at an https:// URL.

If you have a valid login session with Twitter going right now, click here to allow a page to post a message about me to your Twitter.  For the example to work, you’ll need to accept the certificate, however there the same trick will work if the site has a properly signed cert.  There are other situations where HTTP_REFERER is not passed: local files and FTP URLs, for example.

If you want to avoid falling prey to this until it is patched, it’s pretty simple: use a third-party Twitter client and leave yourself logged out of the web-based interface unless you need it at the moment. If you’re a serious Twitter user, you’re probably already doing this.


I’ve posted about this before, regarding Twitter’s signup process, although Facebook’s signup process is probably the most well-known example. Now, I see it on Slideshare. For future reference, when you see this:


SlideShare Fail

Please do this:

SlideShare 2

I’m sure most of my readers can imagine what a bad idea it is to hand their email password over to a third party. What’s more dangerous is that this functionality might become more common. If every social-networking-site-of-the-week integrates something similar into their signup process (and it is attractive for them), then it will become more natural for users to expect it, making them less likely to question it. Overall, it makes phishing a lot easier, as now you have a wider choice of sites you can mimic, or you can just make up something completely new.

Also, at least in this specific case, the credentials you’re handing over are not going over SSL. Who knows what precautions are being taken on the other side of this web application, where it’s actually signing into your email and harvesting out the information. You might be carefully using GMail only over SSL for your sessions with it, but there’s no guarantee that SlideShare/Twitter/Facebook will be doing the same. There’s also no real assurance that your credentials haven’t been cached or stored in some way.

You may make yourself out to be a bad Internet citizen if you utilize these features, as well. I know of at least one case where a user signed up, the site automatically picked up all of his contacts, and immediately spammed out a referral email to every one of them, including mailing lists. Your friends and other contacts might not like this very much.

I think it’s a bad idea, and I hope that it doesn’t become more widespread trend than it already is.

© 2012 McGrew Security Suffusion theme by Sayontan Sinha