In a pentest, what do you do to avoid breaking stuff? – Digitalmunition

Home Forums In a pentest, what do you do to avoid breaking stuff?

This topic contains 1 reply, has 2 voices, and was last updated by  IUsedToBeACave 1 month, 4 weeks ago.

  • Author
  • #232260


    Imagine doing a pentest, finding a vulnerability, exploitation and accidentally break the company’s stuff, like deleting an internal file, or dropping a table
    What do you do to avoid this type of stuff?

  • #232261


    You just don’t break stuff. There are no magic tricks, you either know what you are doing or you don’t.

    Normally if you find an actual exploit, you don’t exploit it. You log that it could be a problem. If you need to do some type of proof of concept, you create an analog system you control that is configured in the same way as the vulnerable system. If the client asks you to actually attempt to exploit the system, then make sure you warn them of the consequences of doing so and then go for it. Eternal Blue is a good example, if you find a server that is vulnerable just let the client know. If the client asks you to exploit it anyway explain that the exploit is unstable it in some cases using it will cause the system to crash. As long as they are OK with that then you can go ahead.

  • #232262


    You avoid breaking things by knowing what you’re doing. You’re a professional for a reason, not a skid

  • #232263


    People who are good in this job don’t just break stuff, and those who are junior or are just starting are not just set loose in the clients environment to wreak havoc as they please. It’s not like you just try out different exploits without understanding what the possible risks are. It’s you job to evaluate what your impact could be.

    If you ever find a vulnerability in a pentest, and are not sure if exploitation could cause harm, you can still report the vulnerability without actually demo’ing it in a real world environment.

    You can still obviously setup a test environment that is as close to the real world scenario as possible and record a demo there for the client to see. In general you are not paid to just mindlessly break stuff because it can be broken, you are paid to consult the client and improve their Security.

  • #232264


    Simply put, you need to know what your doing before doing it.. Research the vulnerability, know how it impacts the system, maybe even test it in a lab first of your not sure..

    Nothing is ever guaranteed. Be cautious.

  • #232265


    In general you have to know what you are doing and test things in none destructive ways. You don’t need to drop a table to test SQL injection. Be careful, usually with clients you have terms written out in advance that says what you can and can’t do. Although it is rare accidents do happen, maybe you touch some piece of data you shouldn’t have or you knock something down. In that case you need to contact your client immediately and be honest.

  • #232266


    You usually have a certain expectation of the effects that a weakness has and you would approach cautiously. But it is always a possibility that things break in an unexpected manner. That’s why you prepare your client, ask them if they have recent backups.

    Better yet, don’t test productive instances. It’s far less problematic if you break the development instance. Encourage your client to provide access to some testing environment where you can wreak havoc without second thoughts.

  • #232267


    It’s pretty hard to accidentally drop a table

  • #232268


    While doing a Penetration Test on the Companies software you are looking for actual Bugs that you can then write down on your notes with a POC (Proof of Concept) without Exploiting t in a way that could cause harm after finishing Pentesting the rest of the Application you report back to whoever hired you and if they tell you to actually exploit it that’s when you do it. You do not just break stuff you need to know what you are doing! You can not just go in and break everything that’s not the Professional way of Penetration Testing

  • #232269


    Use a sandbox

You must be logged in to reply to this topic.