Pentesting Cleanup

Question

I've recently discovered a backdoor shell that was created via file injection on a public facing website. After much digging, I found the creation date of this file to be around the same time pentesting was done by others in the department. Most of this was done by persons not completely experienced with pentesting, and I wondered if one of the tools used injected the file, since in addition to the creation date, no evidence of its use surfaced. I myself will (almost) always do pentesting on a testing instance, vs live, so typically this isn't an issue, but will some of the various software available inject an actual file that creates a backdoor shell, or are the files that are injected "dummies"?

Answer 1

It is quite difficult to tell from the details you have provided. Typically if we had known what sort of software they used for their pentest, we could draw a more educated guess.

I have seen many pentest reports from different companies that were too focused on the technical findings, but very little, almost to nothing, about their methodologies. Having their methodologies clearly scoped and defined is vitally important for the pentest company and for the client both: it's the company's way of covering their own butt for when situations where potential collateral damage occur, and the client's guarantee that if the company side-tracks and, say, bring the company's site down due to a DoS that was not in scope, they can made liable for it.

Because a) pentesters are (or should) be perfectly capable of writing their own tools, and b) because the damage is already done (having a foreign file on your server is never good, whether is a genuine backdoor or a dummy file) your question,

[...] will some of the various software available inject an actual file that creates a backdoor shell, or are the files that are injected "dummies"?

... at this point becomes irrelevant: you have bigger problems at hand here such as 1) determining whether the tool was uploaded by the testers; and 2) the maturing of your pentesting process as a whole. Depending on the findings of 1), other investigations might beg some further attention: what if they claim that the shell was not their tool?

So the key point here is communication. If you are the analyst that facilitated the pentest, or the service owner, nothing will stop you from getting a full report from the testers on their methodology. Feel free to request a meeting to go through their methodology, as this will help you ascertain whether the 'forgotten' shell was a product of their negligence, or not - remember, always assume the worst and at this stage, there is nothing that guarantees that the shell was not a result of a true breach, either prior- or post-pentest.

For future pentests, in order to avoid this situation, make sure that:

1. you have a clear internal process that deals with different situations that can arise from a failed pentest
2. read their Proposal/Statement of Work and don't accept everything they throw over there; demand methodical description of their methodologies. Have clauses that address very clearly who is liable for what
3. Know your assets

---

TL;DR - Summary

It is not possible for me to answer whether the security tools used in your pentest injected actual backdoors or dummy files, because the level of detail you have provided is not enough. Still, even if it were possible, at the current time, this is the least relevant question, and the recommendation is that you confront the pentesters for a thorough clarification.