Wikipedia articles carry with them a revision history that logs every change made to an article, as well as information on the user or IP address that made the change. The revision history and user information can provide someone gathering intelligence with as much or more information about a topic than its article. Many Wikipedia editors are personally connected to the articles they edit, or otherwise have a stake in what is being said, and by processing the revision data, it’s possible to gain some insight into those connections.

This is somewhat awkward and time consuming to do through the web interface, so it helps to automate. I had a need to determine what revisions and users introduced certain phrases in an article, and wrote the following script to help:

To use, first export the article(s) you want to process to XML using Wikipedia’s Special:Export page (be sure to uncheck ”Include only the current revision”). Once you have the XML saved locally, usage is as follows:

./ <xml file> <word or phrase>

The output is comma-delimited and contains the Wikipedia timestamp, user information (username/id or IP address), and a link to the revision that introduced (or re-introduced) the phrase.

Hope this is of use to someone besides myself!



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”:


Earlier today, this was making the rounds on twitter:

It’s a cute-looking manga-style comic about team Sapheads’ experiences with the “Binary 300″ challenge in the Defcon 17 CTF pre-quals.  It’s kind of entertaining, and looks informative, if a bit engrish-y.  I scrolled through it quickly, bookmarked it, and planned to give it a good read later.

At first glance, I especially liked that there was a female character on the team, which I thought could be a very positive thing.  That is, until I saw this making the rounds on twitter later today:

…the above is a discussion of the “Tiffany” character in the comic strip, who turns out to be a ridiculously stereotypical depiction of how some view women and computer security research.  Not only is “Tiffany” an offensive stereotype, she’s a terribly one-dimensional and annoying character, only serving as a foil.  She asks questions about what’s going on to give the other characters a chance to go into detail, acts all confused, and that’s about it.  I suppose the other characters are just too l33t to be able ask those questions of each other.

As far as I can tell from the original Binary 300 write-up and anything else I can find out about the Sapheads, the comic’s characters aren’t based on their actual team line-up.

The author of the Female Stereotypes post also relates her own experiences of how she’s treated as a female in security research, and it’s very eye opening.  I highly recommend reading it, as well as the original PDF writeup of the Sapheads attempt at this challenge.

Edit: The author/artist of the comic updated the page to apologize and explain.  In future comics on other challenges, the “Tiffany” character will serve a more useful role than “cheer-leader”.  It turns out that there is no female member of the Sapheads team, and that the character is based on a famous Korean singer.


If you haven’t read Part 1 of this story, then you really ought to take a look at it first.  It serves as a good overview, and the criminal complaint filed by the FBI is a good read.

Yesterday afternoon was GhostExodus’ detention hearing.  I’m not very familiar with the process one goes through after being arrested for something like this, so I had to look up what this meant.  I found the following site which, I believe, explains detention hearings well:

(Looks like a cool site beyond this, even.  Kind of a legal equivalent to the blog I run here.)

I was informed yesterday afternoon that the Judge in this case found that there was probable cause to detain Jesse McGraw while the case is pending.

Here are some links to the coverage this is getting.  I’m linking articles that I think my readers would enjoy, especially those where the reporters were thorough enough to contact me personally to get the stories:

The members of the press I’ve talked to on the phone and over IM have been very nice.  There are many more stories than this, you can poke around on Google News if you like, but your best source of technical information for fellow security and control-systems folks is going to be right here, of course :)

Now, time to break out the popcorn.  Here are two of the most interesting videos that were posted to GhostExodus’ youtube accounts.  It’s my understanding that these videos were played in court yesterday.  After each video, I’ve summarized some points of interest in each video:

  • “Post July 4th” is a strange choice of title here, as it’s before July 4th, and in preparation for the attacks scheduled for the 4th
  • He’s recording this by holding his laptop in front of him (reflections in elevator)
  • Claims to have infiltrated corporate offices, but it’s obviously a medical facility
  • Watch for medical charts and such on the walls when he sits down
  • Appears to be the collar of a security guard uniform peeking out of the top of the hoodie
  • The FBI identified this computer at the clinic by the toy flamingo on top of the monitor

  • This was recorded at a desk at the hospital where McGraw was a security guard.
  • I thought about buying one of those camera pens until I saw this.  Not inconspicuous.
  • Showing off your fake FBI credentials on youtube isn’t very smart.

I will continue this series with more posts, discussing the HVAC compromise, how I came to be aware of it, and the techniques I used to gather information on the suspect.  Still pooped from talking to so many people about this, but I’m enjoying spreading the gospel of control-systems security ;)


I guest-lectured the computer security class here today, and with it being the day Conficker.C starts looking for a payload, I figured it would be an excellent opportunity to deviate from the normal lesson plan.  With the well-written Honeynet Project and SRI papers out there that describe the technical details of Conficker.C, it’s a great time to expose the students to malware analysis.  There’s some really interesting and clever things that this worm/botnet does, and discussion of it filled an hour’s lecture nicely.

As I promised to the class and to several people on Twitter, I’ve made the slides available here:

…although I fear it won’t be as useful without having been there.  It’s more visual aid and points for discussion than a standalone set of slides you can just read.  Either way, enjoy!

One thing I’d like to talk about in addition to this: the speculation about what Conficker.C will actually do.  The pendulum has been swinging between two extremes of media speculation (“will destroy the internet”-like garbage) and equally ridiculous complete dismissal (“nothing has happened and nothing will”).  Many security professionals, including those that are blogging and posting to twitter, are swinging a little bit too far to the latter I think.  It seems just as dangerous to completely dismiss it as it is to give it too much hype.

Here’s a few things one needs to keep in mind when speculating about Conficker.C and its effects:

  • April 1st isn’t the only important day.  It attempts to find a payload every midnight (local time).  April 1st is just the first day that it does this–it’s not necessarily the day the operator/originator will register domain(s) and deploy a payload.  He/she/they can do this, at their leisure, from now until enough of the infected machines are fixed or go offline to make it not worth it (some time).
  • There’s no reason for the operator to walk away from it.  There’s tons of computers infected, and a really solidly-written means of getting potential payloads spread around.  A lot has been invested in this, and there’s some significant power and revenue to be claimed by whoever can sign a payload for it.
  • Chances are, it’s not going to be loud.  There’s no money in melting the Internet or indiscriminately destroying Windows installations.  This isn’t the Slammer worm choking large parts of the internet with UDP packets spreading itself.  Nowadays folks want to make money with malware, and that means routing spam, harvesting information, and things like that.  The longer an infected computer acts normally, the longer the malware can stay there, run, and generate revenue

So there you have it.  It’s not likely to destroy the Internet, but I would also be very surprised if we don’t see a payload distributed (widely) through it at some point.


When we describe the process an attacker goes through to compromise their target, we usually try to break it up into different phases with terms like reconnaissance, enumeration, probing, and exploitation. This varies when we talk about different kinds of attackers. Some, with no specific target in mind, will skip “casing the joint”, and just scan massive numbers of sites for specific vulnerabilities.

The real bottom-of-the-barrel here is the attacker that tries to compromise a site with a tool meant for vulnerability assessments. These are tools that are not built for any sort of stealth or finesse, because they are meant to be run in the course of a vulnerability assessment by a pentester (using the term loosely here) or systems administrators that want the scan over with quickly. In this case, it doesn’t matter if it leaves a huge signature in the logs or if the IDS screams bloody murder, because the person responsible for tending to those alerts is the person who ran the tool, or is at least aware of the test. This is not as desirable for an attacker who is trying to avoid getting caught or alerting admin/security staff of a breach.

In this specific example, we’ll take a look at some logs generated by an attack launched against this website. The attacker, in this case, is using the Acunetix Web Vulnerability Scanner (likely a pirated copy), and obviously hasn’t thought about what kind of signature it leaves in log files. Those who follow me on twitter and other resourceful readers either already know who this is, or could find out with a little sleuthing and deduction. I haven’t bothered to sanitize the IP address, so you can look through your own logs for traffic like this coming from this guy’s usual range of IP addresses.

Here, I’m going to step through the highlights of the entries that this script kiddie left in my Apache logs. Notice the first two hits from this tool:

20080305.log: - - [05/Mar/2008:02:10:49 -0500]
"GET /acunetix-wvs-test-for-some-inexistent-file HTTP/1.0" 404 240 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:10:49 -0500]
"GET /acunetix-wvs-test-for-some-inexistent-file-second-try HTTP/1.0" 404 251 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

So much for coming in undetected.

This serves a couple of purposes. If you were running this as part of a legitimate assessment, it lets you easily find the place in your logs where your vulnerability assessment started, as well as identify the tool used. I believe that this scanner will also use the response in comparison with other responses later, to determine when files aren’t found, although I haven’t personally used or tested Acunetix.

The tool then indexes the entire target website, apparently not throttling itself at all or making any attempt to disguise itself as normal traffic. I’ll spare you from having to look through the complete logs of it spidering my website, but I will bring your attention to a couple of entries, to show you something interesting:

20080305.log: - - [05/Mar/2008:02:10:57 -0500]
"GET /training/ HTTP/1.0" 200 5176 ""
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:10:57 -0500]
"GET /services/ HTTP/1.0" 200 6405 ""
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

Notice the referral URL? It is explicitly specifying port 80, which would not be necessary or normal for a typical web browser. Throughout the logs Acunetix generated, the referral URL consistently had the “:80″. Once it finished indexing, it tried a few (surprisingly few) simple exploits that didn’t work, and then it was over:

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET /cgi-bin/test-cgi.bat?|dir HTTP/1.0" 404 218 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET /server-info HTTP/1.0" 404 209 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET /server-status HTTP/1.0" 404 211 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET /<<<<<<<<<<<< HTTP/1.0" 404 246 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET /error/%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cboot.ini HTTP/1.0" 404 225 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET /php/php.exe?c:\\boot.ini HTTP/1.0" 404 209 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"TRACE /TRACE_test HTTP/1.0" 200 398 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"DELETE /wvs_test_for_inexistent_file.txt HTTP/1.0" 405 256 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"TRACK /TRACK_test HTTP/1.0" 501 217 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"PUT /web_scanner_test_file.txt HTTP/1.0" 405 246 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET / HTTP/1.0" 200 33894 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

20080305.log: - - [05/Mar/2008:02:11:40 -0500]
"GET / HTTP/1.0" 417 397 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)"

The moral of this story is to realize that, even when it's not in their best interests, lesser-skilled attackers will use tools that are meant for vulnerability assessments in attacks on systems. These tools are usually a poor choice for an actual attack. Acunetix is one example. Even more often you'll see attackers using Nessus to test for every single vulnerability they can. These are tools that are trivial to detect and should be very obvious to an alert administrator. If you use these tools in regular assessments of your own organization, be sure that you're able to determine easily which scans are executed by your staff and which are launched against you by inept attackers.

The attackers that choose these tools typically do so thanks to inexperience. They may feel that if it's used by "professionals", then it must also be good for their purposes. They may not understand the attacks or the process of finding vulnerable services, and therefore rely on a tool that seems like it will do all of the work for them. Pirated commercial tools are often desirable, as the inexperienced attacker might place more value on something that's harder to get, over freeware tools that anyone can download.

I will probably have some more stories about this particular script kiddie coming soon. There's certainly no shortage of material. The absolute master of script kiddie takedowns has a blog at VitalSecurity and is a must-read. I only hope I can be as entertaining with this as he is.

In the meantime between this post and the next, if you think you know who I'm talking about and have had interactions with him in the past, or you're just curious, grep through your access logs for "acunetix" and see if something in the 75.3.*.* ( - to be a little more precise) shows up. If that pops up something, or you see some other unusual activity from that range (admittedly large) send me an email and I might be able to corroborate things from my logs and yours to tie things together. I know for a fact that I'm not the only site he's been playing with ;) .


The Princeton guys that I mentioned in my last post have not released the tools that they used in their paper, yet. I wanted to play around with the way PC’s tend to retain memory, so I’ve written my own implementation of the RAM dumper they describe and show in their videos:

Now, you can try it out for yourself, and see how you can recover text, images, and other data (such as encryption keys!) from memory after the plug has been pulled for a short period of time.


A week ago on the BinRev forums, a link was posted to a site that advertised the ability of the owners to hack any web-based email account. The link was to, however the same site was also available at and (and perhaps more). The cost of this service was $100 per account, and (this is the great part) they would provide proof to you that they had hacked the target account with a screenshot of the inbox. Only then would you have to pay to receive the . You probably know what I was thinking when I read this already ;) .

Here’s what the main page looked like:

I created a new email address on Gmail, with the name of a recent, but inactive, troll on the forums (so there’d be a few things in Google if they decided to do their research). Then, I filled out their order form with the information in the screenshot below, asking them to attack my own Gmail account, . I had to give them something that didn’t look as much like a dummy account. Besides, it’s funnier this way. I had a lot of fun filling out the form asking why they should hack my Gmail account ;) :

A short while later, I received an automated mail confirming my order (very professional!) in my dummy account’s inbox:

A full day later, I received the following phishing mail in my own Gmail account:

A plaintext copy of this email with full headers is available here for those who love to dig :) . I suppose they got around Gmail’s filters by being such a small operation. Does anyone really trust 123greetings-type emails anymore? I guess they must. Notice the domain name, and the just-for-me unique URL. I tried modifying the URL, however it seems like they just generate the files as-needed when they receive an order.

Clicking on the link takes you to the phishing site itself:

Here’s the source for the login form:

For all the domain names they have, and all the web hosts they’ve been using, they had to resort to using a form mail script and leave the email addresses they use for harvesting out in the open. Hilarious.

If you’re a regular reader of this blog, you already know what I like to do with phishing sites (read up here if you’re not familiar with the technique I use to set up web bugs for catching phishers unaware). This one is no exception, so I set up a unique image and page on my site here to use with a web bug. Then I fill out the form fields with the html needed to try and render the image and link to the unique URL:

Once that was submitted, it actually went through the trouble of redirecting me to the real 123greetings for a nice card:

I set up tail and grep to look for a hit to either of the unique URLs I set up, and a day later I got the hit: - - [23/Oct/2007:12:23:19 -0400]
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
.NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506;

So, here you have the IP address (resolves to one of’s customers), which at a glance didn’t appear to be running any sort of open proxy, a referral URL revealing where and how they’re checking their mail (there might be somewhere around 244 other victims, judging from the mail ID), and a nice long user agent string. Judging by the mangled end of the request, my web bugs didn’t render very well within IMP, however the phisher was dumb enough to click on the link anyway. This is the reason I try to put HTML links in along with normal image-based web bugs, and you’d be amazed at how often this happens.

I sent a couple of emails to them inquiring about the status of my order. Unfortunately, I haven’t heard back from them. As of a day or two ago, the sites they were advertising their services on look like this:

I’m sure they’re not very happy about that. Maybe they’ll find this post and leave us a comment bringing us up to speed on their situation ;) .


For some attackers, it’s just a matter of casting it out there to every possible target and hope something sticks. This sort of thing turns up fairly often in my logs, and probably yours too. This time, I’m going to use it to illustrate just how much intelligence you can gather about your attackers if you take some time to investigate. This particular example is a spectacular failure: - - [30/Sep/2007:15:00:26 -0400]
"GET /projects/goosweep/test HTTP/1.0"
404 262 "-" "libwww-perl/5.48" - - [30/Sep/2007:15:00:26 -0400]
"GET /test HTTP/1.0"
404 244 "-" "libwww-perl/5.48" - - [30/Sep/2007:15:00:27 -0400]
"GET /projects/test HTTP/1.0"
404 253 "-" "libwww-perl/5.48" - - [30/Sep/2007:15:00:31 -0400]
"GET /projects/goosweep/test HTTP/1.0"
404 262 "-" "libwww-perl/5.48" - - [30/Sep/2007:15:00:32 -0400]
"GET /test HTTP/1.0"
404 244 "-" "libwww-perl/5.48" - - [30/Sep/2007:15:00:32 -0400]
"GET /projects/test HTTP/1.0"
404 253 "-" "libwww-perl/5.48"

I’m not even very sure what vulnerability they’re trying to exploit here, if any. It almost looks as though they were just testing out their script, and happened to think it was a good idea to run it against a website that specializes in various aspects of computer security. This tells you something about the attackers to start with.

I’m going to cover a few easy investigative tricks you can do to find out more about an attack like this. I’m going to write this as I do it, so information I discuss earlier may be proven wrong by the end of the post. This is intentional, as it’s important to show how theories are formed based on evidence and then thrown out when something is found to contradict them.

First, consider the IP address, . Let’s see what we can find out from it:

  • It doesn’t show up in the logs anywhere else (nor does anything else 195.42.*.*)
    • Most of the traffic in the minutes leading up to the attack are RSS readers looking at the blog. There’s no apparent “looking around” type traffic coming from any other IP addresses in the minutes leading up to the attempts.
    • I wasn’t likely “chosen” for an attack so much as I was automatically spidered from a search query or other site.
  • The IP address reverse-DNS’s to . Dataforce is a Russian ISP.
    • Judging from the hostname, it seems like more of a server for the ISP than an individual’s workstation.
    • So, it’s probably a machine they’ve managed to hack with a similar exploit, and they’re branching out.
  • Looking on google, other sites’ logs and discussion reveal similar things coming from that IP address and host name:
    • Windows 98 user agent?
    • Attempts to grab lots of different php. Looks like attempts to find things they know how to RFI. As recent as in the past 24 hours.
    • Some more attempts at what they did on my site. At least these attempts are better formatted than the ones in my logs:
      • – - [02/Oct/2007:03:44:03 +0900] “GET /admin/index.php?=connection:absolute_path= HTTP/1.0″ 302 284
      • – - [02/Oct/2007:03:44:05 +0900] “GET /index.php?=connection:absolute_path= HTTP/1.0″ 302 284
    • This site appears to be hosted on This supports the idea that this is a shared web host for the ISP’s customers.
    • Several other sites have exposed access_logs revealing connections from, and a handful of other apparent web hosts attempting to RFI the same “infect.jpg”. Examples were noticed where “infect.jpg” was downloaded from other sites, as well. This also supports the idea that this is a branching-out and spreading type of attack.

That’s a good bit of information to gather from one IP address :) . Next, let’s look at the payload, “”:

  • It’s not a real jpg of course. It’s PHP code. I’ve hosted it here, so you can take a look and follow along. I’ve taken out the opening and closing tags, so it’s not effective for remote-inclusion off of my own site ;)
  • Once you take the code and reformat it, you’ll see that it’s designed to spit out a few bits of information about the server, then attempt to run the “id” command to get the current user ID.
    • There’s a big “ex()” function that tries to execute the command in many different ways.
    • This code doesn’t really “do” much, but the results it spits back can be processed to determine if a server running an app vulnerable to RFI has been found. Presumably if it finds something, their script either saves the results in a report, or immediately moves to install a proper backdoor PHP shell.
  • Looks like some french-speaking folk ran across it the other day
  • The author of the script has been busy defacing websites (registration required, and I highly recommend it)
    • Defacing in the name Kurdistan Security Team (with very slick ascii art!).

That about settles matters. For the sake of completion I searched through my logs for other connection that used the same User Agent string, “libwww-perl/5.48″. The only other connections were from another host just yesterday, attempting similar RFI attacks. The IP address turns out to be another shared host, in Germany this time, and the payload had already been taken down.

So what you see here is a shotgun approach to defacing a lot of pages and boosting their name up on Zone-H’s defacement archive. This is pretty basic stuff, but it’s a very interesting exercise to take a few log entries and expand out a profile for the attack and attackers. Hopefully you can apply this to your own incidents.


Last night, a friend pointed out an auction on Ebay Motors that would automatically redirect you to a phishing site. It turns out, the auction had a flash movie embedded that performed the redirect. Here’s the relevant bit of the auction’s code:

I haven’t bothered obfuscating the IP address, so don’t go poking around unless you feel like you know what you’re doing :) . As a matter of fact, for the sake of folks using GooSweep to investigate incidents involving this guy, here’s something for the googlebots to pick up: The IP address is hosting a handful of Ebay Motors phishing sites and flash redirects to those sites..

The host is in Romania, and has been around at least long enough to get its phishing sites indexed by Google. Since there seems to be such a small chance of getting caught and punished for this sort of thing over there, many Romanian attackers are pretty open and carefree about their operations. I wouldn’t be surprised to find out that this box is some old PIII under the phisher’s desk.

Moving on, the flash file itself is pretty interesting. It’s only 172 bytes, and as you can see from the screenshot above, it’s being hosted in a few different places. It may be an attempt to make sure it fails over if the hosting goes down, but I suspect it may be an attempt to throw careless investigators off track. Only the center, highlighted link to ever worked since the time this was spotted. I grabbed the swf, and since it’s so small, my first instinct was to just take a look at it directly:

I don’t know a lot about flash and I didn’t have any flash specific tools on my system, but this is pretty straightforward :) . To make it a bit clearer, I installed flasm (a Flash assembler and dissassembler) out of the Ubuntu repositories and ran it to get the following output:

Again, I don’t know much about Flash, but it’s obviously not rocket science. The attacker defines a function that getURL’s the target, and sets up a call to it in the first frame of the “movie”. It’s pretty trivial to modify this to redirect anywhere, just change the url and use flasm to recompile. I tried this out, so here’s an swf file that’ll redirect you to my blog ;) :

Sample Flash Redirect (.swf)

This is a bad situation for sites like Ebay, with users that demand the ability to have Flash content (such as image galleries, animations, etc.). It’s easy for them to patch up ways to redirect and XSS in the auction’s code itself, but it’s much more difficult to regulate what goes on in Flash objects brought in from other servers. It’s also difficult for Adobe to fix this up in Flash, since I would think that many legitimate sites use the getURL functionality to hop around. I imagine a solution would require sites to have policies on what functionality is allowed and/or disallowed, that the Flash player would have to parse and honor those policies.

© 2012 McGrew Security Suffusion theme by Sayontan Sinha