¿Cuáles son algunas de las cosas que la mayoría de los hackers solían hacer ellos mismos pero que ahora usan el software de otras personas?

Estuve realizando evaluaciones de vulnerabilidad y pruebas de penetración durante la mayor parte de la década de 1990 y el mercado de herramientas era considerablemente menos maduro de lo que es hoy.

La mayoría de los profesionales habían creado y / o recopilado un conjunto de herramientas básicas para enumerar hosts en una red, luego “tomar huellas digitales” o identificar tipos de hosts y sus sistemas operativos, y algún conjunto de código explotado para aprovechar las vulnerabilidades que permitirían Acceso inicial o elevación de los privilegios del sistema.

Hubo algunos intentos notables en la creación de “productos”, pero en su mayor parte se lanzaron como proyectos de código abierto. SATAN de Dan Farmer (también conocido como SANTA si el otro nombre ofendió al usuario y ejecutaron un script para cambiarlo) fue un trabajo fundamental en el sentido de que proporcionaba un tipo de arnés de prueba en el que se podían conectar una variedad de ataques / pruebas, con algo parecido un generador de informes unificado en la parte final del proceso.

Internet Security Scanner era un script de shell con algunas opciones de menú para pruebas seleccionadas, y todavía no era un producto comercial, pero ahorró tiempo para algunas personas.

Hubo cierta consternación en torno a las personas que ofrecían software integrado de prueba / evaluación, ya que a veces parecían integrar capacidades del código de explotación de la prueba de concepto de otros autores, a veces sin permiso.

Entonces, para compromisos profesionales, uno podría usar el escáner de código abierto de alguien (aún no lo llamamos así) para enumerar los objetivos, pero la explotación real recayó en gran medida en el probador para tener o escribir el código de explotación correspondiente para un trabajo. Hubo ocasiones en que, como consultor que realizaba una evaluación de vulnerabilidad o actuaba como pentester, podría tener que escribir un exploit ajustado para trabajar en el sistema de un cliente en particular en medio de un trabajo. A veces eso significaba código de shell para un desbordamiento del búfer, a veces podría haber sido algo similar a la inyección SQL.

La triste realidad (aunque buena para los negocios) era que muchos ataques eran ampliamente reproducibles en cualquier instancia de una versión particular de un sistema operativo o aplicación, por lo que había cierta reutilización incluso en ese momento.

Además, no estábamos arriba iterando manualmente a través de cosas como adivinar la contraseña si supiéramos que el sistema en cuestión filtró información sobre cuentas válidas.

Antes de que los bucles de retardo que aumentaban exponencialmente se convirtieran en una práctica estándar en el software de inicio de sesión del sistema, a veces era posible determinar si un nombre de cuenta era válido incluso si la contraseña era incorrecta, porque un sistema tardaría un poco más en regresar de un intento de contraseña fallido en un cuenta que si la cuenta no existiera. La analogía que usaría aquí es que había una “sensación” que uno podía sentir al hacerlo manualmente, ya que los retrasos de decisegundo en cuestión estaban por debajo de la resolución de las secuencias de comandos de prueba que podría escribir si quisiera automatizar ese proceso. Hacerlo a través de una red solo agrega latencia y hace que sea aún más difícil de automatizar.

En resumen, creo que mi respuesta sería “prácticamente cualquier cosa en Core Impact o Metasploit”.

Fuente: Ayudé a poner en práctica una práctica de evaluación de vulnerabilidad temprana en una startup, trabajé como gerente de producto para una herramienta de escaneo y cofundé una compañía de pruebas de penetración y respuesta a incidentes en la década de 1990.

Alquiler de servidores de uso compartido. En estos días, la mayoría de las personas solo usan máquinas virtuales para sus propios proyectos personales.