Un claro ejemplo de esto es cuando obtenemos una shell en el servidor objetivo y, acto seguido, vemos el contenido de los archivos .bash_history, con todo el historial de los comandos que ejecutó el administrador y algunos usuarios. Quizá esa información cuente hasta con la clave root tipeada por error, o podamos ver el fichero de configuración de red o las conexiones establecidas con las redes y terminales internas. Ahora bien, ¿cómo podemos analizar la información obtenida previamente al ataque? Eso es fácil: una simple cuestión de análisis detallado. Preguntarse para qué nos sirve cada dato es el primer paso. A continuación veremos algunos ejemplos de la utilidad que tiene conocer ciertos datos. El nombre de un empleado de la organización: Para deducir el usuario con cuenta shell en el sistema operativo, una cuenta de correo (u otro servicio de autentificación), para utilizar ingeniería social en cualquiera de sus niveles y formas, para hacer retrieve de algún dato, ampliar el diccionario al utilizar alguna técnica de brute force, para descubrir alguna carpeta o documento online, deducir algún password, comprometerlo para asegurarse acceso con otra identidad en el sistema, para consultar en otros ambientes y bases de datos, etcétera. Cuentas de emails (logins): Si éstas coinciden con el nombre de las cuentas de sistema, se podrán utilizar para conseguir accesos remotos a servidores o terminales. También pueden ser útiles a la hora de conseguir información institucional manejada por el usuario vía e-mail o bien practicar determinado chequeo de passwords por defecto. La plataforma: Sirve para alinear el chequeo a dicha plataforma y sus posibles descuidos, servicios y vulnerabilidades. Veamos un ejemplo muy básico del por qué sirve conocer bien la plataforma o sistema operativo. Supongamos que en uno de los sitios de la organización (nosotros no sabemos que está corriendo sobre el sistema operativo FreeBSD) queremos ver si un script en PHP que está mal programado puede listar el contenido de su archivo (de sistema) passwd*, ingresando este URL en el browser: http://www.sitiovictima.com/file.php?=../../../../passwd%00
Agregarle eso al file.php está mal, porque al ser un sistema operativo FreeBSD, su fichero passwd (típico de Linux) se llama master.passwd, y es éste el query (petición http) correcto: http://www.sitiovictima.com/file.php?=../../../../master.passwd%00 La cantidad de /../ varía según el sistema (Directory transversal issue), la aplicación y el programador, al igual que el uso del carácter NULL del final %00, que puede estar o no. 83