Hey,

While doing a pentest for a client, once we get a bind or a reverse shell on a machine, what should we do and in WHAT ORDER?

• Escalade privileges
• Install useful tools (backdoor, tunnels, etc)
• Enumerate users
• Start cracking passwords to help gain access to other machines
• Erase traces
• Look for interesting files containing database login credentials, sensitive data, etc
• Scan other machines from this host
• Use it as a pivot to attack internal networks

But what else do you do once you own a box?

first of all: root the box! make sure you have administrator privileges. The next step (for black hats) is keeping it. we would probably document it and write a report where we bury the owner of the box...

I agree that for a pentest, cracking passwords is not a good idea. You end up having "sensitive data" (user's passwords) in clear text hanging somewhere and this against the policy of many organizations.

I never went up to installing a rootkit because it requires the box to be rebuild after the test is done. But hummm, I will meditate on this one!

@rvs: Yes, feel proud should be #1 

Though I don't have much experience in real pentesting, I would think pivoting to a server is the aim.  To do that you may need to enumerate users/look for interesting files/etc. but the goal is to get at the database or some sensitive network resource.  Something to make the company go *ouch...* and then THANKS!

jOrDy, I agree with you.

 I would only install a rootkit if I wanted to convince Management people how somebody who has managed to gain root access can actually maintain it.  Installing a rootkit (e.g. by replacing a daemon with a modified one) can also show that probably an Integrity Checking Software may be worth investing in.

I think it depends on the client, but getting root access should be number 1. If your client it a web host, then I would try and gain access to client database info (user,pass) so a remote dump could be made of the data for each database being served. Anything that  show proof that customer info can be compromised would be close to the top as well.

But, then again.. I'm a noob, so I don't know much still.

Depends on the scope of the pentest, are they interested it you can root a box that doesn't do much? Maybe there are much bigger concerns. I'd say pivot, pass the hash etc, then report once you get something juicy, but all depends on what you have already compromised.

    My order:
    * Install useful tools (backdoor, tunnels, etc)
    * Enumerate users
    * Escalate privileges
    * Look for interesting files containing database login credentials, sensitive data, etc
    * Scan other machines from this host
    * Use it as a pivot to attack internal networks


Is erasing traces really necessary in a pentest?

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.