I don't have any experience with that one, but this might be of interest to you if you're interested in Python: http://www.ethicalhacker.net/component/option,com_smf/Itemid,54/topic,5617.msg29578/topicseen,1/

It really depends on the person. I think it's great for me. YMMV.

As far as jobs go, this field seems to be increasingly more popular. It seems like it will stay that way for the foreseeable future.


Like I mentioned before, you really need to be passionate about the material and enjoy working with it. If it's just appealing because you're after a big check or it seems exotic, you're not going to last. It's going to take a lot of time outside of business hours. I would wager that most of us are ok with that because we also consider it to be a hobby.

I also see others get frustrated and quit because they're not willing to put in the time mastering the fundamentals and want to do exciting work right off the bat. Like I said, you'll more than likely have to put in some time as a systems and/or network administrator. You're only going to be able to do a half-assed job (at best) if you don't develop a solid understanding of  TCP/IP first.

What appeals to me is the fact that things are constantly changing, and I'm constantly learning. As you can see, what may be considered a con to some people is a pro to me. That's why the answer to a lot of your questions are going to be, "it depends." I enjoy doing challenging work and having to think critically. Some want a job that's slower-paced with less pressure. I think you get the idea...

Welcome to the forums!

Here's one example of how to go about that: http://www.larsen-b.com/Article/212.html

Googling something like "kismet map gps" will yield many results. There are other utilities that can do similar things (i.e. Netstumbler can collect GPS information as well).

Anytime! Welcome to the forums, btw 


Like I said, titles are all over the place and are not consistent at all. I wouldn't necessarily define an Information Security Analyst that way. I also do risk assessments, IT audits, social engineering, and security awareness training. Penetration tester is just one of the hats I wear.


It's usually pretty difficult to go right into a security role. IMHO, you end up selling yourself a bit short even if you can manage it. You'll more than likely have to get started doing systems and/or network administration and work you way into the security side of things from there. As always, you can't secure what you don't understand.

I would say it's a leap up from anything you'd do in school. I spend hours a day outside of work just trying to keep current and learn things I feel I'm weak in. You really have to enjoy learning and working with this type of stuff as a hobby to really take things to the next level.

Where to start? The women? The money? The fame?

While an information risk consultant might do some ethical hacking, I would expect that role to be focused mostly on risk management. Terminology varies quite a bit in this industry though, so review the responsibilities/qualifications for such a role. "Penetration tester" is the title that's most synonymous with ethical hacker. My official title is "Information Security Analyst," but I also do more than just penetration testing.

Money ranges based on skill. I know some people that make six figures while some of the unskilled newbies we mold right of college make help-desk wages.

I do remote work (i.e. external penetration test) out of our office, and I regularly go on-site (2-3 weeks per month) for the variety of on-site services we perform. I have friends at different companies and they do remote work from home and also go on-site. I wouldn't expect anyone to work professionally from a coffee shop or other semi-public network as there would likely be legal risks involved with that.

As far as the work itself goes, once a penetration test is assigned to me, I work with the client to verify IP address ranges, setup scheduling, address any special needs, etc. Once we're all squared away, the actual testing begins with information gathering, mapping, and so on. Upon completion of the test, I write a detailed report explaining the issues found, what the consequences were, and provide general direction for remediation.  This last part is where I see a lot of people struggle and become unhappy. It's definitely not fun, but it's a necessary evil for a quality test. I spend a significant portion of my time writing reports, so be sure you're able/willing to handle that aspect of the job as well.

We get $4k annually to spend as we see fit (to an extent, it does have to be applicable to what we do and get approved). I probably spend close to that myself on myself though.

That'll do it. Then you can sudo <command> for anything that requires elevated privileges (may need to tweak the sudoers file to your needs).

I know this thread’s a few weeks old, but I wanted to chime in.

Answers to some of these questions are going to depend upon the statement of work and scope you define with the client.

I would say that it is highly unlikely that you would ever be allowed to install root kits, nor should you ever do so as a PoC just to prove a point. That’s a good way to ruin your career and reputation in a hurry. The only plausible scenario I could think of where that would be allowed is if you’re not testing the production network and anything goes; i.e.the organization P2Vs/copies VMs of production systems into an isolated network for testing.

I’d also say the same thing about any software installation in general. Many utilities, especially ones related to networking, can make a lot of modifications/additions to a system, and simply uninstalling the application doesn’t guarantee everything will be undone. Not to mention that there is certainly a wide range of trust regarding where some of our tools come from. You don’t want to unknowingly install something malicious and leave them in worse shape than you found them. I’m hesitant to even run trusted self-contained executables (i.e. pwdump), but sometimes that’s the route you need to go.

Maintaining access goes back to those points again. How are you going to do that? Is it allowed? Is it even necessary? Most places I go to have had the problems I find for months, if not years. Is there a high likelihood that access is going to disappear during the week I’m on-site? This might be more of an issue during multi-week pen tests where the admins are scrutinizing everything you’re doing and working to remedy the issues as they detect them. Also, a particular exploit that gave you access might be unstable, and you may prefer to install something more reliable. Can you do something like enable RDP, SSH, etc. and then firewall it off to the IP you’re testing from? Something like that would be far more ideal than installing a backdoor.

While some organizations may prohibit password guessing/cracking techniques, they are certainly valid techniques, and I use them much more often than not. Obtaining hashes is certainly an excellent get. While there is obviously concern about information sent across the wire in clear-text (this should be a concern for any document you open/transfer), you can take steps to ensure that the information is protected. Enabling SSH in the previous point is an excellent example. If you can run other executables, you can use things like socat, cryptcat, etc. as well.

Your job is to do your best to gain entry the way an attacker would. If you swear off password attacks because they’re against your personal philosophy, and your client ends up getting compromised because a common account is using the 20th entry in the basic JTR password file, you’re going to look like a tool. That’s not to say you should proceed with reckless abandon. Be smart and obtain permission. Understand the configurations in place. Creating a DoS condition because you locked out hundreds of accounts doesn’t count as being “thorough.” If this is a blackbox test, and you aren’t provided with those details, make sure you educate them on the ramifications of such activities.

A coworker of mine destroyed an organization’s OWA with a custom wordlist he made based on people’s names and company information. I would say he compromised close to, if not over, half of the accounts in Exchange/AD. That’s important, and the client was grateful for having the situation brought to his attention.

With the exception of special circumstances where it’s specifically requested (i.e. to test the security administrators), I never see covering tracks being allowed or desired. More often, they want to go back and see if they can piece together what you did and evaluate the monitoring systems they have in place.

I’m not trying to be rude, but I completely disagree with the notion that you should never test live/production systems. That’s all I’ve ever tested, and that’s the vast majority of what all the other analysts I work with have tested. It’s not feasible for a lot of places to have a test/replicated network just for penetration testing. Even if they do, it likely pales in comparison to the production network, and the test won’t yield accurate or meaningful results. That’s not to say that you will always test live/production systems. It’s just been my experience that you will more often than not test live systems, and it really isn’t accurate or realistic to say they should never be tested.

Anyway, lets get to the original question. I would say “most of the above,” but I really like to scavenge. I find all kinds of interesting things in files. Batch/script files commonly have credentials in them. Is it a web app server? Is there a config file somewhere that has db connection strings in it? How about PGP, SSL, or other keys? There are plenty of other documents that have random, interesting things in them. We found a text file on a web server in some directory that was discovered via DirBuster that had tons of PII in it.

Enumerating users, acquiring hashes, local privilege escalation exploits, etc. are all important. There’s no set order for these types of things. It’s going to be a dynamic experience, and it’s going to vary based on your level of access and what else is available. It's more important to be thorough and exhaust all your options that adhere to a rigid methodology. For example, scanning/recon occurs at the beginning, but like you said, gaining access to another system may allow you to scan additional networks. This is a somewhat cyclical process.

The value of pivoting will vary depending on where you’re at. It’ll be much more valuable if you’re doing an external test than if you’re on the same LAN. Gaining access to a DMZ or internal network is probably going to prove to be much more interesting that being on the same network of devices you probably already have network connectivity to. However, you may find a machine that’s dual-homed or has access to machines you don’t (i.e. a database server that is only accessible from the web app server you compromised). Check interfaces, ARP caches, routing tables. Netstat too; are there any services running that are only available locally?

The advice for sniffing is great as well, especially on *nix systems since tcpdump is often already there. If the system is some type of server that performs authentication (especially insecure), that’s a really good strategy. Proxy servers would be interesting too. You can find all kinds of neat stuff going across the wire.

I think this is where realistic goal setting and direction/focus can really help. If you try to learn everything about everything, you're just going to end up spinning your wheels.

You should pick a topic/area that interests you, and determine a realistic time-frame for getting to your desired level of expertise. That's not to say you have to go out of your way to avoid learning about anything else (i.e. covering your ears and running out of the room) if something comes up, but you definitely should have one primary area of study.

I've found its also easier to keep up your momentum/motivation and receive a greater sense of accomplishment as you continually advance. When trying to learn several things at once, you advance far more slowly with each topic and feeling like a novice with many things for an extended period of time gets old.

Running it in a VM is probably the easiest solution. Free solutions such as VirtualBox and VMware Player are more than adequate. You could probably get by with a live CD; it might just be a pain reconfiguring things every session. You could store your files on a thumb drive and automate a lot of that though.

Everything :lol:

Programming, Windows and *nix systems, networking, web apps, databases, etc.

How do we vote? Just PM the man?

He gets my vote as well. He's been making awesome post after awesome post ever since he signed up.

It's one of several VMs I bring along for the ride, but even that one has been changed significantly from the vanilla BT4. Having a bootable USB copy is also nice if you're doing something like a physical walkthrough and you want to demonstrate booting to it off of a public machine (i.e. a kiosk) as a PoC. My main Linux VM is currently Xubuntu 10.04.

Just to be clear, we don't offer remediation for that very reason (remaining unbiased, especially when it comes to IT audits). However, we do make recommendations to give our clients direction for remediation.

For example, in the case of unrestricted zone transfers, I'd inform them that they should limit zone transfers to only the hosts that require them, or disable them entirely if they are not necessary. I don't provide step-by-step instructions for BIND or whatever DNS server they're using, nor do I make the configuration myself. I just try to give them a little push in the right direction.

Some places simply do garbage work. We're often complimented on the detail that goes into our pen tests and vulnerability assessments reports. When I'm writing a report, I explain what the vulnerability is, what the risks are, how it was exploited (or how it was attempted to be exploited), what information/access was obtained, and how to remediate it.

You should review the SoW (statement-of-work) and the contract to make sure expectations are clear, and both parties are on the same page. You should also ask to see sample deliverables.