Thursday, November 6, 2008

The Story of a Hack - Part 1. Reconaisance

If you haven't read the Intro, it might help if you check out that post.

First things first, recon. I want to find out as much information about my target as possible. Some attackers might go straight to scanning IP's , not me, I want to do as little of that as possible at the moment. I start with the best tool I have available for recon, Google!

I scour the targets website. It’s a small and basic website but I get an email address, a flyer in PDF format and a list of office locations and contact details. Well that’s a start. The website is very 1.0, simple and secure I guess.

So the email address I got off the website is a generic mailbox that many organisations create, Well let me I throw the domain name into Google and get a few results.


Okay, So I get a few results.

What is interesting is came up in a SQL Server forum asking a question about MS SQL 2000 Server configuration.

I also use Google to see which sites are linking to HackMe Ltd.

Of the links I get returned the most useful one is from an outsourcing support company called BackupService. They provide small companies with Remote Support and have HackMe Ltd listed as a customer. Interesting, that puts them in scope as a possible attack vector.

Now I turn to the PDF file on the website. I run this through to look at the metadata.

FileType(guessed) = PDF document, version 1.4
format - PDF 1.4 mimetype - application/pdf MIMEType = application/pdf
CreateDate = 2008:04:01 03:39:33
PDFVersion = 1.4 FileType = PDF Creator = PrimoPDF
Title = Microsoft Powerpoint Sales Brochure [Compatibility Mode]
ModifyDate = 2008:04:01 03:39:33

PageCount = 9

FileSize = 243 kB

Producer = PrimoPDF
Author = Lena Bloggs

Okay, after a quick Google, I see PrimoPDF is not vulnerable. But I have got another employee name, Lena Bloggs, and I know that my target uses Microsoft Office internally, so there probably using IE and Outlook too. Mmm, loads of possibilities there for some targeted sploits.

Let's see what I get with a quick bounce email.

I send an email to and have a look at my returned headers.

Delivered-To: Received: from ( Received-SPF: pass ( best guess record for domain of designates as permitted sender) client-ip=; as permitted sender) smtp.mail= X-VirusChecked: Checked X-Msg-Ref:!1225463335!6552390!18
X-StarScan-Version:;,-,- X-Originating-IP: [] Received: from unknown (HELO ( From: To: boundary="" X-DSNContext: 335a7efd - 4523 - 00000001 - 8004546 Message-ID: Subject: Delivery Status Notification (Failure) This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed.

Okay, from my bounce email I get to find out that my target is filtering email for spam and viruses, bugger. That reduces my chances of getting some of my attachments through. I do get the name of an internal server though. I also get some IP addresses.

This is all useful information that will help me decide which attack avenue will be most successful.

Now what have they got on the Internet, I know that they have a web presence and an email server so let’s look at DNS. First I do a Whois to see what that turns up.

So this gives me company and address info, and I also get to see who they use for the Name servers. Nothing too exciting.

Now DNS, For this I will use a couple of tools. Fierce Domain scanner is a favourite of mine, and has served me well before.

perl -dns

This has given me 2 Address blocks. One which will be the hosted website (, and the other looks like the address block they use for there own servers I'll focus on that block. What I really want to know is how big is the range the use and are there any other hosts accessible.

I use nmap to look for typical edge devices on that class C range.

nmap -sP

This gives me what i suspect is the range they are using. with .32 being the network address and .47 being the broadcast.

Now I check the webmail host I found and find that as I expected only port 443 is open.

nmap -F PN

And then I confirm that IIS is in use.

nmap -PN -p443 -sV

So now I find that they are using Microsoft IIS as suspected.

But Fierce didn't give me a mail server. Well, luckily I get that IP from my email bounce ( remember.

After applying some nmap magic dust, I get some very interesting info back. It looks as though my target is using a Cisco pix firewall and they are probably NAT'ing through it to the internal hosts. Again, knowing this will help me shape my attack.

I'll also quickly Dig the MX to verify my bounce email.

dig -t mx

The results confirm what the bounce email found. HackMe is using MessageLabs for mail filtering. Buggers!

Okay, maybe I’ll stretch my legs and go for a little drive. But first I do a quick Google Map of where I'm heading.

Nice, there's a big park right outside my targets office and plenty of streets to park on.

So I stop by the targets office which is in a built up area with plenty of other small businesses around. I can park quite close to the premises and if my IPhone serves me well I see that they have a lovely wireless network going on.

WEP, you are the weakest link, goodbye!

So what have I got from my recon?

External IP Addresses

  • - mail
  • - webmail

Wireless Network

  • HackMe- WEP Encryption



Internal Host Names

  • File-Server

Software in Use

  • MS Office
  • MS IIS
  • PrimoPDF
  • MS Exchange
  • Windows XP
  • Windows 2003 Server
  • MS SQL (maybe)

Other Useful Info

  • Cisco Pix Firewall in use
  • Using MessageLabs for email scanning
  • External Support through BackupService Ltd
  • Head Office is 20 minutes drive.

Not bad for a couple of hours work. This should be fun.

OK, so my attack vectors:

Client side exploits:
I know what software they are using internally so this is certainly a possibility. But I also know that they are filtering mail with a pretty good filtering service so that's not good.

Social Engineering:
I know who HackMe uses for Support, and I know quite a lot about the software they use, the names of HackMe employee's, and the infrastructure they have. This is certainly a good attack vector.

Bruteforce Webmail:
I know that they have an accessible webmail server, and I have some information to make an attempt at bruteforcing a login. I don't have enough info at this point and this would be pretty messy and unlikely to succeed.

Wireless Penetration:
Knowing they use WEP, have named the AP as HackMe and have not hidden the SSID, this tells me a great deal about the security of HackMe. This will be my preferred attack vector.

Lessons Learned

Okay, So what could HackMe Ltd have done to make the attackers life more difficult.

  • Don’t use WEP. It's very broke. Hide SSID's and apply MAC Address filtering.
  • Strip Metadata from documents.
  • Strip Email headers.
  • Minimise Information disclosed by third parties.
  • Don’t post questions to tech forums from a company email addresses that disclose information about your infrastructure.

Coming up........Breaking in and Kung Fu Shopping.


blad3 said...

great post. thanks, i learned something new today (serversniff and the bounce trick).
keep up the good work.

SynJunkie said...

Thanks for the feedback blad3.

ServerSniff is an excellent site, another great one is if your into web based tools.

SynJunkie said...

Thank you to the anonymous person who noticed up my mistake. I removed your comment but I appreciate the fact that you took the time to read my blog entry and comment.

It has been a very long day and I need to proof read more accurately.

KrisTeason said...

Good post synjunkie,

Saw your site from

I'll be coming here more often to read up to see how successful you are...

FireWraith said...

It's also worth mentioning that Maltego is an awesome info gathering tool. And even better now that they have a 'Community Edition', which isn't as good as the full edition but it is free.

SynJunkie said...

That is a very good point. The reason I left it out of this post id because I wanted to have some screenshots and it's pretty hard to do that with Maltego about a fictitious company.

Xme said...

Great post SynJunkie! Waiting for the second part! Keep up the good work...

Mike said...

I have to disagree with your recommendations for securing the wireless. Kismet can easily find the SSID, and though it hasn't been ported to the iPhone yet, you can sit in your car with a laptop. And you can detect (and spoof) a valid MAC by capturing packets.

I'd recommend enterprise-grade security, or at least WPA2.

SynJunkie said...

Mike, i couldn't agree with you more. The point I was attempting to make is that these "layers" of security do offer some level of protection. Yes it is easy to discover hidden SSID's and bypass MAC Address Filtering as I have shown in previous posts, but these measures do raise the bar and the work factor for an attacker.

I also believe that by taking these measures you are giving the attacker a message that you take security seriously, and if you are likely to take these sort of steps to secure your wireless you are also probably likely to secure your internal network also.