LM (Lan Manager) Hash - Brute Force Failing

4

Ho un numero di hash LM che ho cercato di crackare con hashcat. La mia comprensione è stata che LM divide le password in due stringhe di 7 caratteri separate prima di essere sottoposte a hash. Credo anche che usino solo lettere maiuscole, oltre a cifre e caratteri speciali.

Ho tentato di eseguire il seguente comando in hashcat: hashcat64.exe -m 3000 -a 3 lm-out.txt -1 ?u?d?s --increment ?1?1?1?1?1?1?1

Questo dovrebbe forzare la forza bruta ogni combinazione possibile con i caratteri accettabili per LM da 1 a 7 caratteri - tuttavia, dopo aver eseguito questo fino al completamento, ha recuperato solo lo 0,20% di tutte le password?

Mi stavo chiedendo se qualcuno potesse far luce su questo per me? So che la maschera di caratteri speciali di hashcat non include il segno di cancelletto, ma non riesco a capire perché oltre il 99% delle password non sia forzato brutalmente in questo modo? Il fatto che alcuni siano stati recuperati come semplici parole mi porta a credere che non possano essere alterati in qualche modo prima di essere sottoposti a hash.

(Inoltre, io lavoro in sicurezza informatica, quindi questa non è una richiesta "Black Hat" in alcun modo!)

Ho provato gli hash di esempio da hashcat.net/wiki/doku.php?id=example_hashes, per escludere un problema di corruzione degli hash, come suggerito da Rory, ma è riuscito a estrarre circa 20 password dagli hash, che è ciò che mi porta a credere che gli hash non possono essere corrotti o che non c'è un ulteriore livello di sicurezza in qualche modo, perché sicuramente questo influenzerebbe ogni hash, non solo la maggior parte di essi?

Tutti gli hash sono stati estratti contemporaneamente dal file NTDS.dit dallo stesso script, quindi dovrebbero essere tutti ok o tutti corrotti? A meno che non abbia frainteso quel suggerimento?

In relazione alla risposta di Royce (Grazie per la risposta completa):

  • Quando dico sterlina, in realtà sono inglese, quindi intendo letteralmente il simbolo "£" anziché "#". Quando ho controllato il charset dei caratteri speciali sul wiki di hashcat il simbolo "£" non è comparso in quella lista? Dato che si tratta di una discarica di hash inglese, mi sono chiesto se questo potrebbe essere parte del problema? Ci scusiamo per la confusione!

  • Riguardo agli hash che sono stati incrinati - sono tutti o 7 per la prima parte e vuoti per la seconda, o 7 per la prima parte e 1-6 per la seconda. Sono alfanumerici con! come l'unico personaggio speciale. Sono parole reali o parole che sono state storpiate con numeri anziché lettere.

  • Non ho più accesso al sistema di destinazione, ma sicuramente il fatto che alcuni degli hash sono stati incrinati significherebbe che il problema non può essere nell'approccio? Nel senso che quelli che hanno lavorato sono stati estratti allo stesso modo?

  • Non sono sicuro che saprei come scoprire la codepage / set di caratteri predefinito del sistema e poiché non ho più accesso al sistema, non so di poter rispondere a quello. Ci sarebbe qualche differenza tra inglese britannico e inglese americano che potrebbe causare problemi se Hashcat sta assumendo gli Stati Uniti?

  • Se sono stati utilizzati caratteri ALT che hanno forzato la memorizzazione delle password come NTLM, non sostituirebbe tutti gli hash LM per tali password con un hash standard "vuoto"? Questo è qualcosa che mi ha confuso, poiché tutti gli hash non incrinati sono diversi, il che significa che ho assunto che siano hash di valori diversi. Avevo anche pensato che fosse improbabile che oltre il 99% degli utenti usasse caratteri pazzi e non standard nelle loro password! (Soprattutto date le password che sono state incrinate!)

  • Per estrarre gli hash ho creato una copia shadow del volume e ho afferrato NTDS.dit e SYSTEM. Ho quindi utilizzato esedbexport per estrarre le tabelle e ntdsxtract (in particolare dsusers.py) per estrarre gli hash. Penso che questo sia un percorso abbastanza standard, ma posso pubblicare link agli strumenti, o più informazioni esatte sul mio processo lì se lo volessi chiarito.

Ancora una volta, penso che la cosa che continua a lanciarmi è che alcuni degli hash si stanno rompendo, quindi se ci fosse un errore in questo processo, o anche con il charset di sistema, non sarebbe hai reso ogni singolo hash senza senso?

Grazie ancora per il tuo aiuto Royce, molto apprezzato.

(Inoltre, sconsigliare la compatibilità a ritroso con LM è qualcosa che abbiamo già fatto!)

    
posta Chris 02.03.2017 - 12:37
fonte

1 risposta

5

In primo luogo, alcune risposte alle tue meta-domande:

  • hashcat in effetti comprende la suddivisione di 7 caratteri e ottimizza di conseguenza.

  • hashcat sa anche che LM non fa distinzione tra maiuscole e minuscole, quindi è possibile rilasciare il set di caratteri personalizzato senza modificare la velocità dell'attacco.

  • Non sono sicuro di quale sia l'idea che il set di caratteri di hashcat non includa '#'. lo fa sicuramente:

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

Mi aspetto che questo approccio ottenga tutti gli hash ASCII validi a 7 bit:

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

Successivamente, alcune idee per una risposta:

  • L'elenco degli hash che sono stati effettivamente copiati ha qualcosa in comune - set di caratteri, lunghezza, pattern, ecc.? Questo potrebbe darti un'idea di cosa manca.

  • Hai la possibilità di impostare una password conosciuta sul sistema di destinazione? In tal caso, puoi convalidare il tuo approccio direttamente contro un testo in chiaro noto.

  • Qual è la pagina di codice / set di caratteri predefinito del sistema di destinazione? Se non è inglese / Windows-1252 , quindi le cose diventano complesse - il sistema converte la stringa in OEM tabella codici durante la conversione in un hash.

  • Se caratteri ALT vengono utilizzati nella password, alcuni di essi funzionano con le password LM e altri non . I seguenti caratteri ALT non sono compatibili con LM e il loro utilizzo forzerà la memorizzazione della password solo come NTLM, anche se LM è l'impostazione predefinita di 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

Ad esempio, questo è l'hash LM di "cañon", come incrinato da hashcat (disclaimer: ho usato una VM di Windows per usare il metodo di immissione della chiave ALT per generare la stringa, e quindi ho usato John the Ripper's pass_gen.pl per cancellarlo):

272a43bc1fe85832:$HEX[4341a54f4e]

Si noti che se si tenta di replicare questo su un sistema utf-8-ready, si otterrà invece questo risultato, che non è il modo in cui Windows gestisce l'inserimento dei dati:

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

Mi aspetto che questo approccio ne riprenda alcuni:

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

Ma l'uso di caratteri ALT è relativamente raro. Se stai verificando un elenco di password degli hash delle password nel mondo reale, esaminerò la validità dello script di estrazione di hash. Se pubblichi ulteriori informazioni su questo, posso provare ad aiutarti di più.

(Inoltre, la compatibilità a ritroso con LM non dovrebbe essere necessaria nell'azienda moderna e come auditor dovresti avvisare di disabilitarlo. )

    
risposta data 02.03.2017 - 17:23
fonte

Leggi altre domande sui tag