Es bastante difícil distinguir los detalles que ha proporcionado. Por lo general, si hubiéramos sabido qué tipo de software utilizaron para su Pentest, podríamos hacer una suposición más informada.
He visto muchos informes recientes de diferentes compañías que estaban demasiado centrados en los hallazgos técnicos, pero muy poco, casi en absoluto, acerca de sus metodologías. Tener sus metodologías claramente definidas y definidas es de vital importancia para la empresa más idónea y para el cliente: es la forma que tiene la compañía de cubrir su propio trasero para cuando se producen posibles daños colaterales, y la garantía del cliente de que si la empresa se desvía del tema y , digamos, reducir el sitio de la compañía debido a un DoS que no estaba dentro del alcance, pueden hacerse responsables de él.
Debido a que a) los pentesters son (o deben) ser perfectamente capaces de escribir sus propias herramientas, y b) porque el daño ya está hecho (tener un archivo extranjero en su servidor nunca es bueno, ya sea un backdoor genuino o un archivo ficticio) su pregunta,
[...] algunos de los diversos programas disponibles inyectarán un real
archivo que crea un shell de puerta trasera, o son los archivos que se inyectan
"maniquíes"?
... en este punto se vuelve irrelevante: aquí tiene problemas más graves, como 1) , determinar si los evaluadores cargaron la herramienta; y 2) la maduración de su proceso de pentesting como un todo. Dependiendo de los hallazgos de 1) , otras investigaciones podrían pedir más atención: ¿y si afirman que el shell no fue su herramienta?
Así que el punto clave aquí es comunicación . Si usted es el analista que facilitó el Pentest o el propietario del servicio, nada le impedirá obtener un informe completo de los evaluadores sobre su metodología. Siéntase libre de solicitar una reunión para revisar su metodología, ya que esto le ayudará a determinar si la cáscara 'olvidada' fue producto de su negligencia o no, recuerde, siempre asuma lo peor y en esta etapa, no hay nada que garantice que la cáscara no fue el resultado de una verdadera violación, ya sea anterior o posterior al pentest.
Para futuros pentests, para evitar esta situación, asegúrese de que:
- tiene un proceso interno claro que se ocupa de diferentes situaciones que pueden surgir de un pentest fallido
- lea su Propuesta / Declaración de Trabajo y no acepte todo lo que arrojan allí; Exigir la descripción metódica de sus metodologías. Tenga cláusulas que aborden claramente quién es responsable de qué
- Conozca sus activos
TL; DR - Resumen
No me es posible responder si las herramientas de seguridad utilizadas en su pentest inyectaron puertas traseras reales o archivos ficticios, porque el nivel de detalle que ha proporcionado no es suficiente. Aún así, incluso si fuera posible, en el momento actual, esta es la pregunta menos relevante, y la recomendación es que se enfrente a los pentesteros para una aclaración completa.