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.
The day you stop learning is the day you start becoming obsolete.