LM (Administrador de LAN) Hash - Error de fuerza bruta

4

Tengo un número de hashes LM que he estado intentando descifrar con hashcat. Mi entendimiento fue que LM divide las contraseñas en dos cadenas separadas de 7 caracteres antes de que se eliminen. También creo que solo usan letras mayúsculas, así como dígitos y caracteres especiales.

He intentado ejecutar el siguiente comando en hashcat: hashcat64.exe -m 3000 -a 3 lm-out.txt -1 ?u?d?s --increment ?1?1?1?1?1?1?1

Esto debería forzar con fuerza bruta todas las combinaciones posibles con los caracteres aceptables para LM de 1 a 7 caracteres. Sin embargo, después de completar esto, solo se ha recuperado el 0.20% de todas las contraseñas.

Me preguntaba si alguien podría arrojar alguna luz sobre esto por mí. Sé que la máscara de caracteres especiales de hashcat no incluye el signo de libra, pero no puedo entender por qué más del 99% de las contraseñas no serían forzadas de manera brutal de esta manera. El hecho de que algunos se hayan recuperado como simples palabras me lleva a creer que no se pueden modificar de alguna manera antes de ser eliminados.

(También, trabajo en seguridad cibernética, ¡así que esto no es una solicitud de "Black Hat" de ninguna manera!)

Probé los hashes de muestra de hashcat.net/wiki/doku.php?id=example_hashes, para descartar que un hash se corrompiera, como sugirió Rory, pero ha logrado extraer aproximadamente 20 contraseñas de los hashes, que es lo que me hace creer que los hash no se pueden corromper o que no hay una capa adicional de seguridad de alguna manera, ya que esto afectaría a todos los hash, no solo a la mayoría de ellos?

Todos los hashes fueron extraídos a la vez del archivo NTDS.dit por el mismo script, por lo tanto, ¿deberían estar todos bien o estar todos corruptos? A menos que haya entendido mal esa sugerencia?

En relación con la respuesta de Royce (Gracias por la respuesta completa):

  • Cuando digo libra: en realidad soy inglés, por lo que quiero decir literalmente el símbolo "£" en lugar de "#". Cuando verifiqué el conjunto de caracteres de caracteres especiales en el wiki de hashcat, ¿el símbolo "£" no apareció en esa lista? Como también es un volcado de hash en inglés, me pregunté si eso podría ser parte del problema. ¡Disculpas por la confusión!

  • Con respecto a los hashes que se han resquebrajado: todos son 7 para la primera parte y en blanco para la segunda, o 7 para la primera parte y 1-6 para la segunda. ¡Son alfanuméricos con! como el único personaje especial. Son palabras reales, o palabras que han sido destrozadas con números en lugar de letras.

  • Ya no tengo acceso al sistema de destino, pero ¿el hecho de que se hayan resquebrajado algunos hashes significaría que el problema no puede ser abordado? ¿En el sentido de que los que funcionaron se extrajeron de la misma manera?

  • No estoy seguro de saber cómo descubrir el conjunto de caracteres / páginas de códigos predeterminados del sistema, y como ya no tengo acceso al sistema, no sé si puedo responder a eso. ¿Habría alguna diferencia entre el inglés del Reino Unido y el inglés de EE. UU. Que pudiera estar causando problemas si Hashcat asume que EE. UU.?

  • Si se usaran caracteres ALT que obligaron a almacenar las contraseñas como NTLM, ¿esto no reemplazaría todos los hashes LM para esas contraseñas con un hash "en blanco" estándar? Eso es algo que me ha estado confundiendo, ya que todos los hashes sin fisuras son diferentes, lo que significa que asumí que son hashes de valores diferentes. ¡También pensé que era poco probable que más del 99% de los usuarios hubieran estado usando caracteres locos y no estándar en sus contraseñas! (¡Especialmente dadas las contraseñas que se han descifrado!)

  • Para extraer los hashes hice una instantánea de volumen y agarré NTDS.dit y SYSTEM. Luego utilicé esedbexport para extraer las tablas y ntdsxtract (específicamente dsusers.py) para extraer los hashes. Creo que esta es una ruta bastante estándar, pero puedo publicar enlaces a las herramientas, o información más exacta sobre mi proceso allí si quisiera que se aclarara.

Una vez más, sin embargo, creo que lo que me sigue tirando es que algunos de los hashes se están agrietando, por lo que si hubo un error en este proceso, o incluso con el conjunto de caracteres del sistema, ¿no ¿Has hecho todos los trucos de hash?

Gracias de nuevo por tu ayuda, Royce, muy apreciada.

(Además, ¡recomendar la compatibilidad con versiones anteriores de LM es algo que ya hemos hecho!)

    
pregunta Chris 02.03.2017 - 12:37
fuente

1 respuesta

5

Primero, algunas respuestas a tus meta-preguntas:

  • hashcat sí comprende la división de 7 caracteres y se optimiza en consecuencia.

  • hashcat también sabe que LM no distingue entre mayúsculas y minúsculas, por lo que puede eliminar el conjunto de caracteres personalizado sin cambiar la velocidad del ataque.

  • No estoy seguro de dónde obtuviste la idea de que el conjunto de caracteres de hashcat no incluye '#'. definitivamente lo hace:

    $ hashcat --help | egrep ' s .*#'
      s |  !"#$%&'()*+,-./:;<=>?@[\]^_'{|}~
    

Espero que este enfoque obtenga todos los hashes ASCII de 7 bits válidos:

$ hashcat -m 3000 -a 3 -i lm.hashlist ?a?a?a?a?a?a?a

A continuación, algunas ideas para una respuesta:

  • ¿La lista de hashes que realmente se han resquebrajado tiene algo en común: conjunto de caracteres, longitud, patrón, etc.? Esto puede darle una pista de lo que falta.

  • ¿Tiene la capacidad de establecer una contraseña conocida en el sistema de destino? Si es así, puede validar su enfoque directamente contra un texto simple conocido.

  • ¿Cuál es el conjunto de caracteres / páginas de códigos predeterminados del sistema de destino? Si no es inglés / Windows-1252 , entonces las cosas se vuelven complejas : el sistema convierte la cadena al OEM página de códigos durante la conversión a un hash.

  • Si ALT caracteres se utilizan en la contraseña, algunos de ellos funcionarán con las contraseñas de LM, y otros no . Los siguientes caracteres ALT no son compatibles con LM, y usarlos forzará que la contraseña se almacene solo como NTLM, incluso si LM es el valor predeterminado del sistema:

0128-0159 0306-0307 0312 0319-0320 0329-0331 0383 0385-0406 0408-0409 0411-0414 0418-0424 0426 0428-0429 0433-0437 0439-0447 0449-0450 0452-0460 0477 0480-0483 0494-0495 0497-0608 0610-0631 0633-0696 0699 0701-0707 0709 0711 0716 0718-0729 0731 0733-0767 0773-0775 0777 0779-0781 0783-0806 0808-0816 0819-0893 0895-0912 0914 0918-0919 0921-0927 0929-0930 0933 0935-0936 0938-0944 0947 0950-0955 0957-0959 0961-0962 0965 0967-1024

Por ejemplo, este es el hash LM de "cañon", resquebrajado por hashcat (descargo de responsabilidad: usé una VM de Windows para usar el método de ingreso de la tecla ALT para generar la cadena y luego usé pass_gen.pl de John the Ripper para codificarlo):

272a43bc1fe85832:$HEX[4341a54f4e]

Tenga en cuenta que si intenta replicar esto en un sistema listo para utf-8, obtendrá este resultado, que no es la forma en que Windows maneja la entrada de datos:

de3fa2be44e8af61:CAñON (which is 41 43 b1c3 4e 4f)

Espero que este enfoque recoja algunos de ellos:

$ hashcat -m 3000 -a 3 -i lm.hashlist ?b?b?b?b?b?b?b

Pero el uso de caracteres ALT es relativamente raro. Si está auditando una lista de hashes de contraseñas de empresas del mundo real, a continuación analizaré la validez del script de extracción de hash. Si publicas más sobre eso, puedo intentar ayudar más.

(Además, la compatibilidad con versiones anteriores de LM debería ser innecesaria en la empresa moderna, y como auditor debe avisar que lo deshabilite. )

    
respondido por el Royce Williams 02.03.2017 - 17:23
fuente

Lea otras preguntas en las etiquetas