Shuck Hash before trying to Crack it

Magazine
Marque
MISC
Numéro
128
Mois de parution
juillet 2023
Spécialité(s)


Résumé

Le « Hash Shucking » est une approche récente consistant à « éplucher » / « écailler » un hash ou jeton d’authentification vers un algorithme jugé plus faible et donc plus optimisé pour le cassage. Cette technique s’applique particulièrement bien pour les algorithmes reposant sur le DES, notamment les jetons NetNTLMv1.


Body

1. Introduction et contextualisation

Lors d’audits offensifs internes, à l’encontre de cibles privilégiées comme les écosystèmes Active Directory, une très grande majorité des attaquants-auditeurs débutent en boîte noire avec une action d’écoute passive / active / man-in-the-middle du réseau via des outils comme Responder [RES] pour obtenir des challenges d’authentification. Une impersonation WPA2-Enterprise permet aussi d’obtenir de tel challenge (hostapd-wpe [WPE]) ou encore une capture d’une négociation PPTP-VPN MSCHAPv2 ($99$) via chapcrack [CHA].

De telles actions en tâche de fond permettent de récolter des jetons d’authentification sous divers formats, notamment NetNTLM, avec possibilité de forcer le downgrade avec Responder (--lm ou --disable-ess, quand le client dispose de la clé du Registre lmCompatibilityLevel < 3 [PRA]).

Bien que déconseillé de nos jours, le protocole d’authentification réseau NetNTLMv1 (introduit en 1993, figure 1) se base sur du chiffrement symétrique Data Encryption Standard [DES], dont l’insécurité au regard des puissances de calculs actuelles n’est plus à démontrer. Le NetNTLMv1 a par la suite été durci avec la notion de ESS/SSP (Extended Session Security / Security Support Provider), permettant d’inclure un autre challenge renforçant l’aléa final.

shuck01-s

Fig. 1 : Schématisation haut niveau du protocole d’authentification NTLM [CSA].

Parmi les nombreuses méthodologies de compromission d’un accès initial largement documentées, l’obtention d’un NetNTLMv1 par des auditeurs est souvent le premier sésame pour pénétrer le domaine.

Avec un NetNTLMv1, un attaquant peut chercher à :

  • Casser celui-ci via hashcat [HAS] pour obtenir le plaintext (brute-force, wordlists, etc.) : ce qui est chronophage, sans assurer un résultat à 100% ;
    • Méthode prolifique si la complexité du mot de passe est discutable, ou s’il est présent dans des fuites de données passées ;
    • Méthode non prolifique dans le cas d’un NetNTLMv1 d’un compte machine (coercion), car mot de passe machine autogénéré et complexe ;
    • Cette technique est locale (on-premise), et dépend de la puissance de calcul disponible (coût matériel).
  • Casser celui-ci via le service en ligne Crack.Sh [CSH], employant des rainbow tables non publiques dédiées à des FPGA [RAI], pour obtenir un format intermédiaire, à savoir le NT-hash, qui, indépendamment de la complexité du plaintext restant inconnu, permet de réaliser des attaques pass-the-hash [PTH] ;
    • L’usage de cet outil implique d’envoyer sur un service tiers une information très sensible : le NetNTLMv1, ce qui est rarement autorisé/souhaité lors d’un audit ;
    • Le cassage du NetNTLMv1 vers le NT-hash est quasi instantané et gratuit si, et seulement si, le NetNTLMv1 a la valeur 1122334455667788 (rainbow tables) pour son challenge et n’est pas renforcé via ESS/SSP ;
    • Dans les autres cas (challenge différent, ou présence de ESS/SSP), Crack.Sh propose toujours de le casser, mais avec plus de temps et un coût de $20 à $200 ;
    • Reposer sur un service tiers en ligne implique de subir ses indisponibilités, comme ce fût le cas où Crack.Sh était en maintenance plusieurs mois fin 2022.

Le protocole d’authentification NTLM, et notamment NetNTLMv1 avec ou sans ESS/SSP reste technique à appréhender et est souvent incompris des auditeurs qui pourtant manipulent de tels outils, au même titre que d’autres formats de jetons basés sur DES comme MSCHAPv2, PPTP-VPN, $99$, etc.

Le présent article est voué à éclaircir le fonctionnement du NetNTLMv1(-ESS/SSP) ainsi que présenter la méthode de Hash Shucking employée par l’outil en ligne Shuck.Sh [SHU] et sa version on-premise ShuckNT [SNT] pour shucker des NetNTLMv1 vers les NT-hashs instantanément et sans surcoût. Cette approche est complémentaire-préliminaire à l’usage de Crack.Sh ou de hashcat.

2. Qu’est-ce que le « Hash Shucking » ?

2.1 What the Sh*ck !?

Le Hash Shucking ou Password Shucking est une approche optimisée de cassage de secret présentée en 2020 par Sam CROLEY (Chik3nman) à la DEFCON [DEF].

L’idée, synthétisée, est la suivante : imaginons un site web d’e-commerce, comportant 10M de clients inscrits et dont les mots de passe sont simplement hachés en MD5 (sans sel ni poivre). Le site subit une fuite de données et les 10M de MD5 se retrouvent dans la nature.

De nombreux attaquants s’attellent à casser ces 10M de hashs. Ils en obtiennent 80% en clair, soit 8 000 000. Il y a donc 2M de hashs non cassés.

Après la découverte de cette fuite, et invocation de la CNIL / RGPD, le site web d’e-commerce décide de passer tous les mots de passe en Bcrypt (plus robuste cryptographiquement).

Toutefois, les équipes techniques ne peuvent pas attendre que chaque client réinitialise son mot de passe. Alors, ils décident d’appliquer un bcrypt(md5()), pour que tous les hashs en base soient dorénavant au format Bcrypt (sans avoir eu connaissance ni besoin du plaintext).

Seulement, rebelote, le site web subit une nouvelle fuite de données et tous les hashs Bcrypt, incluant les nouveaux inscrits depuis la première fuite et ceux ayant renouvelé leur mot de passe, se retrouvent également dans la nature quelque temps après (disons 15M de hashs Bcrypt).

En tant qu’attaquant :

  • Il est possible de chercher à casser tous ces Bcrypt (15M) à partir du dictionnaire des 8M de plaintexts obtenus lors de la première fuite. Cette approche sera lente (Bcrypt est très consommateur) et non-optimisée, car chaque plaintext sera d’abord haché en MD5 avant d’être haché en Bcrypt. De plus, de nombreux hashs Bcrypt seront testés alors qu’inutiles (les clients s’étant inscrits entre la fuite n°1 et n°2). Pour finir, les 2M de hashs MD5 non cassés suite à la première fuite ne font pas partie des tests menés dans le dictionnaire source.
  • Une meilleure option pour l’attaquant est donc de tester tous les hashs MD5 issus de la fuite n°1 (10M) en les confrontant à la fuite des Bcrypt. Il en déduira la sous-liste des Bcrypt dont les hashs MD5 restent inchangés entre les deux fuites. Puis, avec ce sous-ensemble de MD5, il déroulera ses attaques (brute-force / dictionnaire) beaucoup plus rapidement.

Ce principe se nomme le Hash Shucking : l’idée est qu’à partir d’un secret protégé par un algorithme robuste (Bcrypt), le fait de revenir à un autre format intermédiaire du secret (MD5) facilite et optimise l’obtention du sésame final. Autrement dit, on « épluche » / « dé-coquille » / « écaille » le secret pour s’attaquer à une couche plus faible.

2.2 Hash Shucking et NetNTLMv1

Ce principe de Hash Shucking s’applique très bien pour les jetons d’authentification NetNTLMv1.

En effet, un NetNTLMv1 (ou un quelconque algorithme basé sur DES comme MSCHAPv2, PPTP-VPN, $99$, etc.) se calcule ainsi (figure 2) :

shuck02-s

Fig. 2 : Dissection de la génération d’un jeton sans ESS/SSP.

 

  1. À partir du NT-hash de l’identité (qui correspond au MD4 du plaintext après conversion en UTF-16 Little-Indian), ce hash est divisé en 3 parties nommées PT1 (7B), PT2 (7B) et PT3 (2B) ;
  2. Chacune de ces 3 parties subit quelques opérations binaires pour être dérivée en 3 clés K1, K2 et K3 de 8 octets chacune. La dérivation de PT3 (2B) en K3 (8B) induit une faiblesse, évidemment.
  3. En parallèle, un aléa de 8 octets appelé challenge est produit :
    • Cet aléa est généré par le serveur (malveillant). Donc sa valeur peut être prédéfinie (1122334455667788 dans le Responder.conf) ;
    • Pour renforcer significativement la sécurité, la notion de ESS/SSP peut être utilisée, où un second aléa est également généré, sur lequel l’attaquant n’a pas le contrôle. Celui-ci est placé dans la LM-response avec un padding de 0 (figure 3).
    • Le challenge final est donc le client-challenge lui-même en cas d’absence de ESS/SSP, ou alors les 8 premiers octets du MD5 de la concaténation du client-challenge et du server-challenge en cas de ESS/SSP.
    • Donc si une LM-response a 8 octets puis plusieurs 0 en bourrage, c’est qu’il y a présence de ESS/SSP.
  4. À partir des 3 clés secrètes K1, K2 et K3, l’algorithme symétrique DES-ECB est appliqué sur le challenge final pour produire trois chiffrés CT1, CT2 et CT3 de 8 octets chacun.
  5. La concaténation de ces trois chiffrés forme la NT-response qui est directement incluse dans les jetons finaux.

shuck03-s

Fig. 3 : Dissection de la génération d’un jeton avec ESS/SSP.

Au regard de l’algorithme pour générer des NetNTLMv1(-ESS/SSP), on remarque clairement que la source initiale est le NT-hash, et non pas le plaintext directement. Ainsi, le principe de Hash Shucking peut s’appliquer parfaitement pour cet algorithme basé sur DES : revenir à un NT-hash à partir d’un NetNTLMv1, sans avoir besoin de casser ni avoir connaissance du plaintext initial. Surtout que dans un écosystème Active Directory, avoir un NT-hash équivaut à un plaintext grâce au pass-the-hash !

Le fonctionnement de cet algorithme a été implémenté de manière ludique, détaillée et dynamique sur Shuck.Sh dans le Generator [SHU].

3. Casser du NetNTLMv1(-ESS/SSP)

3.1 Les différentes méthodes

La figure 4 résume les couches/coquilles d’un NetNTLMv1 (plaintext / NT-hash / DES keys / NetNTLMv1) et les modes d’attaques existants pour shucker et revenir à une couche antérieure.

shuck04-s

Fig. 4 : Résumé des couches cryptographiques d’un NetNTLMv1 et des attaques associées.

À partir d’un NetNTLMv1, avec ou sans ESS/SSP et quelle que soit la valeur du challenge, il est possible pour un auditeur (dont la prestation est limitée dans le temps), de :

  • Utiliser Shuck.Sh / ShuckNT (on-premise) en premier lieu, pour tenter de shucker le NT-hash instantanément en le confrontant à l’énorme base de données de HaveIBeenPwned [HIB]. Résultat non-garanti, mais permet de gagner un temps précieux.
  • Employer hashcat (moyennant la puissance matérielle) pour :
    • Retrouver le plaintext directement (mode 5500) via des wordlists et/ou masks/rules. Les résultats ne sont pas garantis et cela nécessite du temps (vitesse moindre) ;
    • Retrouver le NT-hash (mode 27000), la vitesse est plus rapide, et tout dépend de la qualité du dictionnaire de NT-hashs fourni ;
    • Casser les clés DES K1 et K2 (K3 étant obtenue instantanément) via le mode 14000 [KPA]. 100% de réussite, quel que soit la complexité initiale du mot de passe ! Mais un tel traitement prend maximum 15 jours avec une machine dédiée (RTX 3080Ti / i7 12th Gen / 32GB RAM pour mes tests), 7,5 jours en moyenne. Ce qui est généralement trop long lors d’une prestation. Une fois les deux clés obtenues, la reconstruction du NT-hash final peut se faire à la volée sur le Converter [SHU] de Shuck.Sh.
  • Employer Crack.Sh pour 100% de résultats (si disponible) :
    • Quasi instantané et gratuit si le NetNTLMv1 est dépourvu de ESS/SSP et que le challenge a pour valeur 1122334455667788, quelle que soit la complexité du mot de passe initial ;
    • Sous quelques heures moyennant $20-$200 en présence d’ESS/SSP ou avec un challenge différent de 1122334455667788.

La technique du Hash Shucking employée par Shuck.Sh / ShuckNT ne remplace pas hashcat ni Crack.Sh, mais permet potentiellement de gagner du temps, sous réserve que le mot de passe ait fuité précédemment.

Mais comment est-il possible de shucker quasi instantanément un NetNTLMv1 vers son NT-hash, sans l’usage de rainbow tables / FPGA, ni d’un supercalculateur, alors que hashcat et Crack.Sh effectuent leurs traitements en plusieurs dizaines de minutes voire heures ? Détaillons le fonctionnement de Shuck.Sh et de son moteur ShuckNT.

3.2 Déterminer PT3 du NT-hash à partir du NetNTLMv1

Comme évoqué dans la description de l’algorithme pour générer des NetNTLMv1, la partie PT3 (2 derniers octets) du NT-hash sert à concevoir la clé DES K3 qui permet l’obtention du chiffré CT3 sur 8 octets. Une faiblesse en découle, il suffit de tester toutes les valeurs entre 0x0000 et 0xFFFF pour redéterminer les 2 derniers octets (PT3) d’un NT-hash à partir d’un NetNTLMv1 [HAU][EVI].

Un tel brute-force est instantané et est implémenté sur le Converter de Shuck.Sh de manière dynamique.

En connaissance de la fin d’un NT-hash instantanément à partir d’un quelconque NetNTLMv1(-ESS/SSP), une nouvelle optimisation en découle, couplée au Hash Shucking, dans le but de retrouver le NT-hash complet rapidement : l’utilisation de HaveIBeenPwned !

3.3 HIBP-DB à la rescousse !

Le service de Troy Hunt, HaveIBeenPwned [HIB], qui agrège, informe, notifie et contribue grandement à l’amélioration de l’hygiène des mots de passe au travers des fuites de données qu’il référence, fourni une base de données complète en libre téléchargement de tous les précédents mots de passe qui ont fuité par le passé, hachés en NT-hash.

Cette base, dont la v8 fait plusieurs Go pour 847 223 402 mots de passe fuités, se structure comme suit, avec #leak le nombre de fois où le mot de passe a été observé dans les fuites recensées :

NT-hash:#leak
ycam@shuck> head -n3 pwned-passwords-ntlm-ordered-by-hash-v?.txt
00000001F4A473ED6959F04464F91BB5:4
000000034C209E9CA85D03512759C405:3
0000000CEB20FBC9D76790D7F9E6E22B:1

Comme il est possible de déterminer instantanément les 4 derniers caractères d’un NT-hash en hexadécimal à partir d’un NetNTLMv1, pourquoi ne pas chercher dans l’énorme base de données de HIBP tous les NT-hashs qui terminent également par ces mêmes caractères, puis les tester un à un afin d’essayer de shucker le NetNTLMv1 ?

Seulement, rechercher parmi ces presque 850M de NT-hashs de HIBP uniquement ceux finissant par 4 caractères précis peut s’avérer chronophage si la technique de recherche n’est pas optimisée...

3.4 Recherche binaire dans une base optimisée

Un algorithme de recherche binaire peut parcourir une gigantesque base de données triée, avec une approche dichotomique, à la recherche des valeurs (de taille fixe) débutant par les mêmes 2 octets de manière très efficiente.

Afin d’optimiser une telle recherche, la base de données de HIBP doit être convertie :

  1. Pour chaque NT-hash qu’elle contient, inverser ceux-ci pour qu’ils débutent par les caractères de PT3 inversés. Soit :
    00112233445566778899AaBbCcDdEeFf:#leak
    # devient :
    fFeEdDcCbBaA99887766554433221100:#leak
    • Suite à cette inversion de tous les NT-hashs (prends plusieurs minutes), il est nécessaire de retrier tous les NT-hashs alphabétiquement ou « hexadécimalement » parlant (également plusieurs minutes) ;
    • Finalement, comme chaque ligne n’a pas toujours la même taille (le #leak peut parfois être très important), il est nécessaire de convertir cette énorme base de données-inversées-triées en un format binaire. Le nombre d’occurrences #leak étant un int, 4 octets suffisent (toujours plusieurs minutes).

    Avec ces modifications à n’effectuer qu’une fois, la base de données est optimisée pour une recherche binaire instantanée, et est également fortement réduite en termes de taille (plusieurs Go de gagnés).

    ycam@shuck> head -n3 pwned-passwords-ntlm-reversed-ordered-by-hash-v?.bin|hexdump
    0000000 0000 0800 97d5 5afb 42ed e7b0 5b41 49f6
    0000010 0000 1200 0000 0a00 c1ba e015 36c9 33d4
    0000020 f82c 6d2e 0000 0800 0000 0a00 09ee 0e13
    0000030 a4c9 c9ea 2227 c7a2 0000 0100 0000 0f00
    0000040 7690 c17e 1a00 d415 2b5f 1efc 0000 0500
    0000050 0000 1b00 81c2 c191 8fd1 4451 00b7 03d8

    En moyenne, il y a ~12 650 NT-hashs qui « finissent » tous par les 2 mêmes octets dans la base de données HIBP v8, soit que ~12 650 NT-hashs à tester pour shucker un NetNTLMv1 et non pas les ~850M.

    3.5 Ready to shuck!

    Avec tous ces éléments, le Hash Shucking du NetNTLMv1 avec ou sans ESS/SSP et quel que soit le challenge peut se faire, et ce instantanément via la recherche binaire dans la base HIBP.

    Bien évidemment, les résultats dépendent de la base de données, et il n’est donc pas possible de garantir à 100% l’obtention du NT-hash.

    L’algorithme final de shucking consiste donc à :

    1. Extraire CT1, CT2 et CT3 d’un NetNTLMv1(-ESS/SSP) ;
    2. Brute-forcer les 65 536 valeurs possibles des 2 derniers octets du NT-hash PT3 correspondant à K3 et donc CT3 ;
    3. De là, effectuer une recherche binaire dichotomique dans la base de données HIBP de tous les NT-hashs terminant par PT3 ;
    4. Pour chacun de ces NT-hashs (~12 650 en moyenne), extraire PT1’ et PT2’, dériver K1’ et K2’ puis calculer les CT1’ et CT2’ correspondants (avec le challenge du NetNTLMv1 initial) ;
    5. Si CT1’ et CT2’ sont identiques au CT1 et CT2 du NetNTLMv1 initial, alors le NT-hash a été shucké !

    Cet algorithme est celui employé par le moteur ShuckNT, utilisable en local ainsi qu’intégré sur la version en ligne Shuck.Sh.

    Cet outil détaille et dissèque un NetNTLMv1 pour y retrouver tous les éléments cryptographiques servant à sa composition (CT1, CT2, CT3, client-challenge, server-challenge, final-challenge, K1, K2, K3, PT1, PT2, PT3, etc.) jusqu’à l’obtention du NT-hash si présent dans la base de données HIBP.

    4. Fonctionnalités additionnelles et synthèse

    4.1 Les autres formats

    Dans cet article, les jetons au format NetNTLMv1 sont détaillés. Pour mémoire, le format des NetNTLMv1 sans ESS/SSP est le suivant (incompatible Crack.Sh / compatible hashcat / capture via Responder [RES]) :

    login::domain:lmresp:ntresp:clientChall
    *::*:[a-fA-F\d]{48}:[a-fA-F\d]{48}:[a-fA-F\d]{16}
    Prefix: N/A / Delimiter: ":" / Hex / Optional login, domain, lmresp

    En cas de présence de ESS/SSP, un 0’s-padding est visible dans la LM-response (incompatible Crack.Sh / compatible hashcat / capture via Responder [RES]) :

    login::domain:lmresp(serverChall+0padding):ntresp:clientChall
    *::*:[a-fA-F\d]{16}[0]{32}:[a-fA-F\d]{48}:[a-fA-F\d]{16}
    Prefix: N/A / Delimiter: ":" / Hex / Optional login, domain

    Le format gratuit attendu par Crack.Sh lorsque le challenge est fixé à 1122334455667788 et qu’il n’y a pas d’ESS/SSP est le suivant (on note l’absence du challenge, incompatible avec hashcat) :

    (LM|NT)HASH:ntresp
    (LM|NT)HASH:[a-fA-F\d]{48}
    Prefix: (LM|NT)HASH / Delimiter: ":" / Hex

    En présence d’ESS/SSP, et/ou quand le challenge final est différent de 1122334455667788, le format payant destiné à Crack.Sh est (on note la présence du challenge, incompatible avec hashcat, capture via hostapd-wpe [WPE]) :

    $NET(NT)?LM$challenge
    $ntresp$NET(NT)?LM$[a-fA-F\d]{16}$[a-fA-F\d]{48}
    Prefix: $NET(NT)?LM$ / Delimiter: "$" / Hex

    Pour les authentifications WPA-Enterprise et PPTP-VPN qui reposent également sur le NT-hash et DES, les formats peuvent être les suivants (incompatible Crack.Sh et hashcat) :

    $MSCHAPv2$challenge$ntresp
    $(login)?$MSCHAPv2$[a-fA-F\d]{16}$[a-fA-F\d]{48}$*
    Prefix: $MSCHAPv2$ / Delimiter: "$" / Hex / Optional username

    Ainsi que le format $99$ destiné initialement à (feu) CloudCracker, mais compatible avec son successeur Crack.Sh (capture via chapcrack [CHA]) :

    $99$b64encode(hex2bin(challenge+{ntresp=CT1+CT2+PT3})
    $99$[a-zA-Z\d\+/]{35}=
    Prefix: $99$ / Delimiter: "$" / Base64

    Tout ces formats sont donc équivalents bien que certains ne soient compatibles qu’avec hashcat ou Crack.Sh. Il est aisé de passer de l’un à l’autre et tous sont convertibles avec Shuck.Sh / ShuckNT, via le Converter.

    À titre d’exemple, le jeton suivant $99$ESIzRFVmd4i8671kB52wcm9qK5VdJR7lJKU= pourrait être soumis à Crack.Sh moyennant $20-$200. En le soumettant à Shuck.Sh / ShuckNT, celui-ci n’est hélas pas shucké, mais il est converti au format NTHASH:BCEBBD64079DB0726F6A2B955D251EE57D6DD8A109D77A0D, qui lui est gratuit sur Crack.Sh !

    4.2 Synthèse

    Via le moteur ShuckNT [SNT] intégré à la version en ligne Shuck.Sh [SHU], il est possible de :

    • Retrouver instantanément et gratuitement le NT-hash associé à un jeton, qu’importe la présence de ESS/SSP ou la valeur du challenge, si celui-ci a déjà fuité ;
    • Convertir un jeton d’authentification d’un format à un autre (MSCHAPv2 vers NetNTLMv1 vers $99$... et vice-versa) ;
    • Optimiser les formats des jetons non-shuckés vers un format potentiellement gratuit sur Crack.Sh [CSH] ;
    • Générer automatiquement les lignes de commandes optimisées pour passer le jeton à hashcat (mode 5500, 27000 ou 14000) [HAS] ;
    • Brute-forcer instantanément les 2 derniers octets du NT-hash [HAU] ;
    • Régénérer le NT-hash suite à l’obtention de K1 et K2 [EVI] (après un hashcat mode 14000, Known Plaintext Attack [KPA]) ;
    • Utilisable en ligne (avec des exemples fournis) ou on-premise pour garantir un contrôle sur toutes les données sensibles issues de vos prestations ;
    • Comprendre, disséquer, générer vos propres jetons sous divers formats avec vos propres valeurs de manière dynamique.

    Conclusion

    Ce nouvel outil s’incruste dans la chaîne méthodologique des audits offensifs internes, en préliminaire de l’utilisation de Crack.Sh et/ou de hashcat qui peuvent induire du temps supplémentaire, des coûts additionnels, ou s’avérer tout simplement incompatibles avec certains formats de jeton.

    Shuck.Sh et son moteur ShuckNT sont nés suite à la mise en maintenance / indisponibilité de Crack.Sh pendant plusieurs mois fin 2022, et dans l’objectif d’être indépendants d’un service tiers lors de prestation d’audit.

    Cet article et ces outils s’orientent vers la famille d’algorithmes fondés sur DES en utilisant les NT-hash comme base de clés. Le NetNTLMv2, quant à lui, suit les mêmes concepts que le NetNTLMv1 à la différence des algorithmes cryptographiques sous-jacents qu’il emploie (HMAC-MD5 au lieu de DES). En conséquence, ce format n’est pas compatible ni avec Shuck.Sh/ShuckNT, ni avec Crack.Sh.

    Ces outils contribuent de plus à démontrer à la communauté que l’usage d’algorithmes basés sur DES n’est plus jugé sécurisé. Au sein des écosystèmes Microsoft Active Directory, il est recommandé d’évincer les versions protocolaires NetNTLMv1 (avec ou sans ESS/SSP) voire même NetNTLMv2 en favorisant l’usage de Kerberos.

    Pour finir, je tiens à saluer et remercier toute la communauté cybersécurité œuvrant au quotidien pour améliorer la sécurité (et l’insécurité) lors d’audits internes, Troy HUNT pour le fabuleux service HaveIBeenPwned ainsi que l’équipe de Crack.Sh, Hashcat et evilmog pour leurs outils d’une grande qualité. Salutations également à mon cher Zarbibi, qui m’a bien aidé lorsque les calculs binaires me procuraient des maux de crâne et à Tmenochet pour sa relecture attentive :) !

    Références

    [RES] Laurent GAFFIE, Responder.py, https://github.com/lgandx/Responder

    [WPE] Brad ANTONIEWICZ, hostapd-wpe (Wireless Pwnage Edition), https://github.com/OpenSecurityResearch/hostapd-wpe

    [CHA] Moxie MARLINSPIKE, chapcrack, https://github.com/h1kari/chapcrack

    [PRA] Adam CROSSER, NTLMv1 vs NTLMv2: Digging into an NTLM Downgrade Attack, https://www.praetorian.com/blog/ntlmv1-vs-ntlmv2/

    [DES] Wikipedia, Data Encryption Standard, https://en.wikipedia.org/wiki/Data_Encryption_Standard

    [CSA] 0xcsandker, NTLM Authentication: A Wrap Up, https://csandker.io/2017/09/10/NTLMAuthenticationAWrapUp.html

    [HAS] Hashcat team, Hashcat, https://hashcat.net/

    [CSH] Crack.Sh team, The World’s fastest DES cracker, https://crack.sh/

    [RAI] David HULTON, desrtfpga, https://github.com/h1kari/desrtfpga

    [PTH] Wikipedia, Pass the hash attack, https://en.wikipedia.org/wiki/Pass_the_hash

    [SHU] Yann CAM, Shuck.Sh, Shuck hash before trying to crack it, https://shuck.sh/

    [SNT] Yann CAM, ShuckNT, on-premise engine of Shuck.Sh, https://github.com/yanncam/ShuckNT

    [DEF] Sam CROLEY, What the Shuck? Layered Hash Shucking,
    https://www.youtube.com/watch?v=OQD3qDYMyYQ

    [HIB] Troy HUNT, Have I Been Pwned?, https://haveibeenpwned.com/

    [KPA] Atom, How to make use of the DES KPA mode, https://hashcat.net/forum/thread-5832.html

    [EVI] evilmog, ntlmv1-multi - ntlm-to-des, https://github.com/evilmog/ntlmv1-multi

    [HAU] Hashcat team, Hashcat-utils – deskey_to_ntlm and ct3_to_ntlm,
    https://github.com/hashcat/hashcat-utils



    Article rédigé par

    Par le(s) même(s) auteur(s)

    DisseXSSion d’un payload générique

    Magazine
    Marque
    MISC
    Numéro
    125
    Mois de parution
    janvier 2023
    Spécialité(s)
    Résumé

    Les vulnérabilités XSS, omniprésentes et très communément remontées lors d’audits de sécurité, pentests et Bug Bounty, restent mal considérées et sous-évaluées. Les protections et spécificités des navigateurs modernes ainsi que les contre-mesures applicatives complexifient la conception de payloads génériques. Cet article vise à présenter la dissection d’un payload dans un contexte (très) contraint et filtré rencontré lors d’un audit.

    Les derniers articles Premiums

    Les derniers articles Premium

    Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

    Magazine
    Marque
    Contenu Premium
    Spécialité(s)
    Résumé

    Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

    Bash des temps modernes

    Magazine
    Marque
    Contenu Premium
    Spécialité(s)
    Résumé

    Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

    Présentation de Kafka Connect

    Magazine
    Marque
    Contenu Premium
    Spécialité(s)
    Résumé

    Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

    Le combo gagnant de la virtualisation : QEMU et KVM

    Magazine
    Marque
    Contenu Premium
    Spécialité(s)
    Résumé

    C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

    Les listes de lecture

    11 article(s) - ajoutée le 01/07/2020
    Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
    8 article(s) - ajoutée le 13/10/2020
    Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
    10 article(s) - ajoutée le 13/10/2020
    Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
    Voir les 67 listes de lecture

    Abonnez-vous maintenant

    et profitez de tous les contenus en illimité

    Je découvre les offres

    Déjà abonné ? Connectez-vous