I have a shell. Now what?

Viewing 16 reply threads
  • Author
    • #5172


      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?

    • #32727

      Feel proud!!! Feel happy  document everything for references. As what my colleague told me:
      1. SCAN
      2. RECON
      3. ATTACK
      4. Anything goes (I am pretty sure you have a procedure to follow right?!)
      My suggestion educate your client  ;D

    • #32728

      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…

    • #32729

      as jOrDy mentioned, the step’s I’d follow and then include in my report would be:

      1) escalate privileges
      2) install rootkit to maintain access

      I believe this sometimes may be enough. Anybody may understand that once this is accomplished everything is at stake.

      However, following or not further steps depends if this pentest was against a Bastion Host or an internal element. If it is a Bastion Host then I would proceed further from the DMZ to penetrate internal systems. If it is an Internal element then one would probably end the procedure.

      What I would not do is crack passwords. I don’t see a point in it.

      Congratulations! having the first shell is extremely important!

    • #32730

      What I would not do is crack passwords. I don’t see a point in it.

      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  ;D

    • #32731

      Pwn and pivot. Use the box your rooted as a base to attack other assets in the organisation.


    • #32732

      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!

    • #32733

      @H1t M0nk3y wrote:

      What I would not do is crack passwords. I don’t see a point in it.

      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!

      my opinion would be that this is beyond the scope of a (ethical) penetration test, and even moving it towards a grey hat penetration. there is no reason to maintain access. any other opinions on this one?

    • #32734

      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.

    • #32735

      Usually if I could get a meterpreter shell on a box, I’ll make use of the sniffer feature. This has come in handy for me several times!

    • #32736

      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.

    • #32737

      Anything that  show proof that customer info can be compromised would be close to the top as well

      Yes, proving that critical services could be down due to an attack and sensitive information could be stolen is the goal of a pentest. So I get the point that once I have rooted a box, I should focus on the main goal: showing to the client that they are vulnerable and tell them how to fix the problem.

    • #32738

      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?

    • #32739

      covering tracks will most of the time not be necessary giving the fact that you should NEVER pentest a live host/system. Chances are that when the pentest is complete, the host will be reinstalled.

    • #32740

      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.

    • #32741

      Instead of installing root-kits, would it be accepted installing LogMeIn on the remote machine and putting it in your logmein database to “simulate” a backdoor?  I mean, if i get a shell its not sure i would get further access in the close future, so getting back in after my powernap without re-running any exploits… Or?

    • #32742

      Why not create Command & Control server

Viewing 16 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?