1. Password Cracking 201: Beyond the Basics
We’re only on the first slide and this slide is already outdated.
There are only 7 cats in this chassis, but I’m told that 8-, 9-, and even 10-cat systems are being developed.
Royce Williams
BSidesLV, Ground1234! track – July 26, 2017

2. Overview About me About you (Types of password crackers)
A brief 101 – password cracking and psychology
Cracking constraints
Core attacks and common pitfalls
Bootstrap tips
Questions 2

3. Disclaimers
My interpretation of some community consensus (mostly from hashcat & John the Ripper)
I am not a lawyer and this is not legal advice
Your organization or jurisdiction may be different
Warning: may irritate and/or bore the experts
I’ve had to gloss over some of the corner cases and details, which may bug some of the global experts in the audience. There will be an errata page – please let me know after the talk :) 3

4. About me $DAYJOB in InfoSec in the financial sector ISP scars
Independent security researcher
Password auditor and enthusiast
Enjoys long keyboard walks on the beach 4

5. About you (types of password crackers)
Infrequent audit/recovery (means to an end)
Internal password auditors
Password auditing consultants
Pentesters
Forensic investigators
Researchers / academics
Competition participants
Enthusiasts
Bounty crackers
… and black-hat equivalents of some of these
These can (and do) overlap
So you might say that there are many sub-disciplines of password cracking … with a lot of overlap, and a lot of opportunity to cross-pollinate 5

6. Learn from other disciplines
* Follow and interact with the people outside of your discipline.
* Read their work - but more importantly, study their goals.
* Most have a common interest in efficiency within time constraints
… but there are other common interests
* Some disciplines – pentesters, auditors - grok password selection patterns across many organizations.
This is a competitive advantage - often not published, so pay attention when it is
* Follow others outside of your discipline. Read their work, but more importantly, learn more about their goals.
* Most in common: focus on time constraints – but there are others!
* Pentesters and cross-org auditing consultants know a lot more about password selection patterns across many organizations, but this is a competitive advantage, so often not fully published 6

7. Password activities: a taxonomy (draft)
Work directly for entity that owns the hashes?
Clear hash ownership?
Authorized by user?
Authorized by hash owner?
Recurring against same targets over time?
Restricted time period?
Exposed to a wide variety of plains over time?
Exposed to a wide variety of hash types over time?
Infrequent recovery (means to an end) Y N
varies
Internal corp password audit
N/A
Password auditing (consultants)
Internal pentest (red team)
External pentest
Internal forensics (staff InfoSec) ?
External forensics (LE)
Password research
measure
Competition: well-sourced, timed
Competition: well-sourced, untimed
Competition, poorly-sourced, timed
Competition, poorly-sourced, untimed
Cracking for bounty (forums, etc.)
Enthusiast activities
Bad guy activities
As I was thinking about the different kinds of password crackers, I started to build a little matrix of what they have in common and how they differ from one another.
INTERESTING QUESTIONS
* Who owns the hashes?
* Who owns the password? (Many people clearly have an expectation of privacy , just based on which passwors they choose)
* Is the activity restricted by a specific time period?
* What kinds of hashes and plains are the likely targets? 7

8. Prerequisites and assumptions
1. You want to crack passwords:
more consistently
with more results sooner
with better understanding
… and to continually improve over time 8

9. Prerequisites and assumptions
2. You have general password-cracking software ...
FOSS
Free (as in beer), closed source
Commercial
* I left out some specialized and commercial packages (Anyone using something not listed here?
* Some great OPEN SOURCE under the hood. The latest L0PHTCRACK (7, released last August after a long break) uses a DLL-ified John the Ripper . Passware’s Forensic Kit is bundled with Tableau Password Recovery. Sagitta HPC’s HASHSTACK is now a full commercial fork of Hashcat (and hashcat now has an API)
* To improve, FOSS is king, for a couple of reasons.
* First, a lot of innovation is happening there.
* Second, FOSS is a great training ground. There are GUIs, but skip them (at least at first). Drive a stick shift first.
* If you use a commercial suite, consider FOSS for learning. If your software is FOSS under the hood, new features may hit the FOSS side first. And if you’re paying for support for those commercial packages, you can open a ticket to request those new features. 9

10. Prerequisites and assumptions
3. You have some hashes (an offline attack):
$2a$12$2mMZzXhVGss5HlGZGKTgjuacYzlOgLoqwkHdeDSS5/7232t/ZluNq
_q amnbqWdjdfs
$sha1$15100$jiJDkz0E$E8C7RQAD3NetbSDz7puNAY.5Y2jr
f3bbbd66a63d4bf ec3d e21d
SCRYPT:1024:1:1:MzM0NA==:LdHQwHIciz9N1HZQ9O1eOkxKCCgnW+Sv015WpZ2Su3A=
$1$ $grgZw95/LN9eIXxaETHv00
$apr1$ $skwyr2o88OWLGaSUqdMGK.
Administrator::24FCC5E8753EA7DCAD0C0724C88E0133:91D95FEFFC9963CC759FC4B338BDE1BB:::
36BYJUMId/4AM
* My next assumption is that you already have some hashes.
* I won’t be covering how to acquire target hashes or how to extract them from AD or a UNIX shadow file.
* A lot of work has gone into making the John the Ripper project the go-to place for tools to extract hashes and put them in a target format. The hashcat project tells users to use john’s tools.
* Note that I say offline attack here to distinguish from online attacks (web login pages, etc), for which controls like throttling and CAPTCHAs are in play
* Yes, these are all real hashes - they’re not very hard.
bba55a0d356d3af89354f6cd7c95b571
51c4d477273a064c
t5a8soeju4i8khkrcctu3cp4ddi1ac8i:.bsideslv.org: :1 10

11. Prerequisites and assumptions
4. You are familiar with hashing for password “storage”:
Not stored, but hashed (one way; resulting string is fixed length)
Some are salted (good); others are unsalted (naive/outdated)
Salts slow down cracking large lists, not individual hashes
Some hashes are slow (bcrypt) – bad for the attacker
Others are fast (unsalted MD5) – good for the attacker
If you are saying “decrypted” or “dehashed” … No.
Good overview: (Pornin)
* You are familiar with how password hashing works.
* Passwords are not stored; they are hashed
* They can be salted or unsalted
* Some are slow (take more processing to hash), some are fast
* And by the way...
[advance: +1]
* If you are saying “decrypted” … in this context, we are not “decrypting” hashes. Some orgs do store passwords encrypted, but this should be rare - and probably harder to get right.
* And don’t get me started on “dehashing”. Some people are actually saying this. This is not only nonsensical, it deeply mis-states the core idea of the irreversibility of hashing. If you are saying “dehash”, STOP. :) 11

12. Prerequisites and assumptions
5. You know some basic password cracking attacks:
Straight wordlist / dictionary
Rules (“password” + “c $1” = “Password1”)
Combinator (list (“za”, “b”, “c”) produces “bza”, “cza”, “zab” …)
Masks (“?u?l?l?l?d?d?d?d?s” - matches “Fall2017!”)
Hybrid dict+mask (lucky?d = lucky1, lucky2 …) or mask+dict
Brute force (?a?a?a?a?a = all six-char ASCII passwords)
Masks and bruteforce guess in an intelligent order (Markov)
* STRAIGHT or wordlist mode
* COMBINATOR, which concatenates each word from two or more wordlists
* MASKS
* RULES - How many of you are familiar with the rules syntax as used by InsidePro, John, or hashcat? Their rule lists are not identical, but they’re basically dialects of each other with a lot of overlap, especially for the common rules.
Hashcat comes with some sets of rules. Some commercial products support rules; others don’t
* BRUTEFORCE – usually only for shorter lengths or a limited time
* *Masks and pure bruteforce both usually guess in an intelligent order (using Markov chains) 12

13. Prerequisites and assumptions
6. You know some basic password management psychology
Human memory is finite
We compensate for this with chunking 13

14. Chunking
* If I ask a chess master to memorize this board, they would have a pretty good chance of doing so.
* If you know nothing about chess, it’s much harder.
Because chess experts can “chunk”, they strongly outperform novices
in board layout memorization tasks for valid chess games ...
Source: Stangor, Introduction to Psychology, Ch 8 (fair use) 14

15. Chunking
* But if I made a “nonsense” board … the chess master’s advantage is gone, and they perform no better at the memorization task than novices.
* It would be like asking someone who only speaks English to memorize a list of Finnish words – they would just be a jumble of letters instead of a single, whole word
… but when presented with a random board layout, experts perform no better
Source: Stangor, Introduction to Psychology, Ch 8 (fair use) 15

16. Chunking Experts memorize complex board layouts efficiently,
because they can
“chunk” the
board into sets of
familiar patterns
The experts chan chunk the board.
Sort of like a pointer to that location in their human memory!
Source: Gobet, 2011 in re Chase and Simon 1973 (fair use) 16

17. Chunking in password schemes
“My son’s name, all lower case, with his birth year at the end”
kevin1963
... is (very roughly) five “chunks” of information:
A specific person’s name
The case of the name
Their specific birth year
The length of the birth year (YY vs YYYY)
The method/order of appending (vs. “1963kevin”)
Cracking guided by known chunking strategies
is much less expensive than bruteforce
*Here’s a rough example of how people use chunking when trying to remember passwords.
[advance: +1]
Cracking that takes advantage of this chunking dramatically reduces the search space.
* The real-world password entropy is dramatically less than if this password was nine random characters 17

18. Attacking the chunks
To crack many passwords using the ‘kevin1963’ scheme:
Wordlist: Facebook names (in frequency order):
Attack: Appending digits to a wordlist (hashcat, on GPU):
$ ./hashcat -a 6 -m 0 test.md5 -j l facebook.txt ?d?d?d?d
For all of SkullSecurity’s Facebook name wordlists (2010):
Here’s one way you would attack all passwords using that scheme, using hashcat.
* In the real world, long before we tried a hybrid wordlist+mask, “kevin1963”(and many passwords like it) would have been cracked much earlier, because it happens to appear in RockYou, but we’ll ignore that for now.
If you’re working with a fast hash, or you have extra time for the attack, you can exhaust all possible combinations.
So here’s the hahscat command line
** “A 6” for hybrid wordlist + mask,
** “j l (lower case l) for the rule that drops case on the entire input word
** facebook.txt (just the first names)
** and a four-digit mask
THAT’S THE END of THE REVIEW of CRACKING 101.
* Let’s move on to talking about ... 18

19. Source: https://www.flickr.com/photos/tanj/3838754485/ - CC-BY-2.0
Cracking constraints
Cracking constraints – the factors that limit performance
Source: - CC-BY-2.0 19

20. Cracking constraints: Math/physics
The exponential nature of bruteforce
Source:
See also Rob’s blog post:
And his talk at Passwords ‘13:
The first major constraint is the nature of bruteforce.
Somewhere between 9 and 10 characters in the full ASCII keyspace, you hit this exponential wall, where the number of guesses required to exhaust the keyspace goes through the roof.
I can’t really improve on Rob Graham’s excellent commentary on this – follow the links at the bottomfor his blog post and the video of his talk – very educational 20

21. Cracking constraints: Math/physics
The exponential nature of bruteforce – crosscheck
$ python -c 'print 95**2'
9025
$ python -c 'print 95**3'
857375
$ python -c 'print 95**4'
$ python -c 'print 95**5'
$ python -c 'print 95**6'
$ python -c 'print 95**7'
$ python -c 'print 95**8'
$ python -c 'print 95**9'
$ python -c 'print 95**10'
Assume that we have no idea what characters might be used, (other than that they are printable ASCII / 95 characters)
Here we have some simple Python commands that calculate the total number of possibilities of a password using the 95 printable ASCII characters.
This is an overly simple example, but using the command line to cross check your assumptions is a very valuable skill for improving your cracking performance.
For now, just note that last value – 5 x 10 to the 19th.
< This is 5.9x1019 21

22. Cracking constraints: Math/physics
The exponential nature of bruteforce - crosscheck
# Benchmark for MD5 (mode 0), 6x GTX 1080, no overclock
$ hashcat -b -m 0 --quiet
Hashtype: MD5
Speed.Dev.#1.....: MH/s (52.74ms)
Speed.Dev.#2.....: MH/s (54.48ms)
Speed.Dev.#3.....: MH/s (53.72ms)
Speed.Dev.#4.....: MH/s (53.82ms)
Speed.Dev.#5.....: MH/s (53.70ms)
Speed.Dev.#6.....: MH/s (53.64ms)
Speed.Dev.#*.....: GH/s
Here’s a hashcat benchmark for MD5 on a rig with six GTX 1080s init, assuming ideal conditions (single hash, optimizations for strings under a certain length, no salt, etc.)
That’s 149 *billion* hashes per second. That seems respectable, right? 22

23. Cracking constraints: Math/physics
The exponential nature of bruteforce - crosscheck
$ hashcat -b -m 0 --quiet --machine-readable
1:0:1746:4513:53.02:
2:0:1733:4513:54.12:
3:0:1771:4513:53.67:
4:0:1746:4513:53.81:
5:0:1721:4513:53.10:
6:0:1784:4513:53.47: = hashes/sec
# Hours to exhaust ?a at length 8
$ python -c 'print ( / )/60/60' 12
# Days to exhaust ?a at length 9
$ python -c 'print ( / )/60/60/24' 48
# Years to exhaust ?a at length 10
$ python -c 'print ( / )/60/60/24/365'
* To make it easier to throw this number into our sanity check, we can use the MACHINE-READABLE flag
* I’m showing you this to illustrate the potential for automation here.
* Over time, you’ll need to refresh this You need this data to plan your attack – and BENCHMARKS CAN AND WILL CHANGE over time!
* New card? Lost a card in the middle of a contest?
* But back to my broader point – notice that last value down there. That’s our 5x10 to the 19th value. Even with s, that’s 12 years. 23

24. Cracking constraints: Math/physics
Take-home lesson: if your target plains are 14-char random, give up trying brute force.
Be ready to cross-check your intuitions.
Use Wolfram Alpha, Python, etc. to do the math 24

25. Cracking constraints: Math/physics
How long should your random password be?
ceil( logC (H * Y * [sec/year]) )
C = charset count
H = adversary hashrate
Y = years to crack
Source rant:
So here’s that math to check whether Jeremi is right.
Is 20 characters really overkill?
What’s an extreme threat model? 25

26. Cracking constraints: Math/physics
How long should your random password be?
ceil( logC (H * Y * [sec/year]) )
(Assuming: C = alphanum (62 chars), H = 100TH/s, Y = 100 years)
... the non-Moore’s-law-aware answer is 14 characters:
IoI8Oasu93H6oN
XxCp8KekKhR1A6 vnhkx7qMNOpGHo
TKheK2Mzkw63IP s
(and per the anrieff.net calculator, w/Moore’s Law, it would be 16 years 2 months)
If we make some extreme assumptions:
** 100TH/s
** 100 years
** And we restrict the character set to U / L / digits
Taking Moore’s Law into account, it’s still 16 years.
Side note: the link is to the equivalent calculation query on Wolfram Alpha. Until you get fluid enough with your language of choice to do these calculations on the fly on the command line, Wolfram is great
* One of the reasons it’s great is that you can do a lot of it with natural language. 26

27. The link is to the equivalent calculation query on Wolfram Alpha
The link is to the equivalent calculation query on Wolfram Alpha. Until you get fluid enough with your language of choice to do these calculations on the fly on the command line, Wolfram is great
* One of the reasons it’s great is that you can do a lot of it with natural language. 27

28. Cracking constraints: Math/physics
How long should your random passphrase be?
ceil( logC (H * Y * [sec/year]) )
(Assuming: C = 17K word dictionary, H = 0.1TH/s, Y = 1 year)
= 5 words, regardless of other complexity
cain mystery ahoy discourse serpent
stares perkiness begs fleshy form
eternal belonged sane allowing disc
Adjust the parameters based on your threat model
Add trivial complexity for any sites that require it
Notice that there are no upper case, no numbers, no special characters in there – just some nice, mobile-friendly lower-case words.
And if you’ve got a site or IT department with naive complexity requirements, throw in whatever complexity is easiest for you to remember, because it doesn’t matter.
May seem off-topic, but I’m beating you over the head with this because closing the gap between your intuition and the reality of the math is fundamental to your advancement. 28

29. Cracking constraints: Math/physics
Just in case you’re also worried about time travelers
or inter-dimensional aliens:
Landauer's principle: theoretical minimum energy of one bit flip of information
The mass-energy of the sun = operations (Pornin)
225 bits = 35-character (95 printable ASCII) passwords
(Hat tip: James Wu 29

30. Cracking constraints: The target
Speed of the hash
You can be lazy experimental with faster hashes
Slow hashes = harder w/o knowledge of target
Size of the target
61M SHA1 from a public leak? Try it all!
A single WPA2? Target knowledge needed
Your knowledge of the target
Some good OSINT tools - but there is a limit
Demographics and sophistication of the target
Requirements (usually detectable)
THERE ARE THINGS ABOUT THE TARGET ITSELF THAT WILL ALSO CONSTRAIN YOU.
You can’t control these directly, but you *can* prepare for them.
How many SHA1 hashes can your GPU hold before it chokes … using hashcat? What about John? What if you throw a hundred thousand rules in there as well? Find out in advance!
Again, these are all interrelated. 30

31. Cracking constraints: Capabilities (1)
Software availability and algorithm support
Cracking technique awareness
Your available attention / energy / motivation
* Now we’re finally getting to some high-leverage stuff that is more under your control.
* Sofware: You can’t crack it if it’s an algorithm no one has implemented. (But note that John the Ripper has a “dynamic” mode where you can express custom variants of MD5 and SHA1-based hashes. See doc/DYNAMIC)
* Techniques: focus on the ones you’re curious about, and expand from there. If your goal is to round out your skills, practice on different targets and hash types. 31

32. Cracking constraints: Capabilities (2)
Raw cracking-specific compute capability
Your ability to turn target knowledge into inputs
Quality of inputs (wordlists, rules, masks, etc.)
Initial attack “spin-up” / prep latency (script this!)
* Now we’re finally getting to some high-leverage stuff that is more under your control.
* Sofware: You can’t crack it if it’s an algorithm no one has implemented. (But note that John the Ripper has a “dynamic” mode where you can express variants of MD5 and SHA1-based hashes. See doc/DYNAMIC)
* The more you prepare, the more focus you can bring to the fun part of cracking. There’s a saying about tools – that when you have a good one, you forget it’s there. If you’re having to stop to think about your tools, that’s an opportunity in disguise.
* Compute capability is linear 32

33. Platform considerations
Source: Flickr user kentwang - CC BY-SA 2.0 33

34. OS / hardware / admin hints
Use the native OS (not a VM) if you can
Kali’s OpenCL and Intel OpenCL are problematic
Use the latest stable video drivers, not OS stock
Use the john “jumbo” & latest hashcat releases …
… but also keep betas and latest GitHub available
… and make it easy to quickly run any of them
For NVIDIA GPUs, use reference/Founders models
Very hardy, built to exact NVIDIA specs
Consider locking fan speed (80%? 100%?) based on your thermal risk models 34

35. Use the FOSS, Luke ... No arbitrary caps on target size Scriptable
Multi-OS, multi-platform
Cross-pollination among projects
Opportunity to directly contribute
stdin … and stdout 35

36. … but embrace the Dark Side ;)
Ease of use
GUI
Canned wordlists and rules
Often good attack-plan management
Built-in distributed processing
Some suites have free trials
Some free front-ends (Hashtopussy, Hashview) have similar features
* Commercial products have their advantages as well
* Ease of use: GUI, attack plans, distributed processing
* Advantages fall directly under “optimizing your attention and energy”
Note:
Some suites have free trials
Some of the free front-ends have similar features to commercial offerings 36

37. ¿Por que no los dos?
Use both FOSS and commercial – whichever are the right tools for your use cases
It’s Free to add FOSS. And some non-free are very affordable
Play with all of them. More exposure = more perspective
Press your vendors for more interoperability (stdin/stdout support), custom rules, etc.
Interoperability: if your suite does not support reading from stdin and sending to stdout, request them from the vendor. 37

38. Input management
Source: 38

39. Wordlist management (1)
Focus on human-generated strings
Quality over quantity
Single best public source for founds: hashes.org
Based wholly on public leaks (AFAICT)
Lists both found and remaining hashes, per leak
Has an API for submission of new founds
For slow hashes, bulk harvest from context (CewL, Maltego, etc.)
* Deduplicate – both globally, and based on type
* rli and rli2 from are the go-to tools for de-duplicating wordlists – extremely fast, and preserve original order
* Retain the raw data for a couple of reasons:
1. Extracting, sorting and deduplicating are expensive
2. It’s easy to make mistakes, especially when you’re learning.
* I usually move the raw data to spinning disk, and keep production data on SSD. 39

40. Wordlist management (2)
All human-generated strings are fair game
Wikipedia/Wikia (long tail of fictional words/phrases)
Domain names and hostnames (Rapid7 Project Sonar DNS ANY)
Usernames / addresses / given/family names …
Street addresses, lyrics, movie subtitles, Project Gutenberg ...
In other words – things that people remember that you can harvest in bulk
These need to be normalized and deduped
Sraveau did a couple of great extracts from Wikipedia
There’s an updated one from January 2017 at the link 40

41. Wordlist management (3)
Deduplicate by type (superset of all addresses, etc.)
rli and rli2 from hashcat-utils are the go-to tools
Build a superset, but retain per-source dictionaries
Watch RuraPenthe’s talk on wordlist grooming:
Some people import into databases … mixed consensus
Probably a 301-level activity :)
I prefer plain text files (the trade-off is more disk space)
* Deduplicate – both globally, and based on type
* rli and rli2 from are the go-to tools for de-duplicating wordlists – extremely fast, and preserve original order
* Retain the raw data for a couple of reasons:
1. Extracting, sorting and deduplicating are expensive
2. It’s easy to make mistakes, especially when you’re learning.
* I usually move the raw data to spinning disk, and keep production data on SSD. 41

42. Wordlist conversion If not in UTF-8, convert to UTF-8 with iconv
… but keep the originals
HTML escapes? Use RuraPenthe’s rurasort
Deduplicate – both globally, and based on type
Use rli from hashcat-utils – very fast, and preserves original word order
Retain the raw data for a couple of reasons:
1. Extracting, sorting and deduplicating are expensive
2. It’s easy to make mistakes, especially when you’re learning.
I usually move the raw data to spinning disk, and keep production data on SSD. 42

43. Baseword extraction
Stemming - deriving original base words from plains
“Ground1234!” → “ground”
More difficult than it looks – aspell, neural networks
RuraPenthe’s rurasort – lots of different options
Stemming wordlists – especially plains/founds - is important because humans invent strings that are not found in other kinds of dictionaries
* Different sources need different methods
* RuraPenthe’s rurasort.py is a great toolkit for this – many different ways to carve up the source words
* And you need to user different combinations of options, depending on the nature of the source data 43

44. Mask management Grab other people’s masks, like KoreLogic’s
Make your own from your previous and current cracks - use PACK’s statsgen and maskgen
Clients who don’t let you keep plains might let you keep stats
Keep masks sorted by frequency
If you get a new list of masks, remove ones that are already exhausted.
Hashcat’s .log files note when they are exhausted (and you can harvest / diff the list)
Status code definitions are in include/types.h, STATUS_*
Stemming wordlists – especially plains/founds - is important because humans invent strings that are not found in other kinds of dictionaries
* Different sources need different methods
* RuraPenthe’s rurasort.py is a great toolkit for this – many different ways to carve up the source words
* And you need to user different combinations of options, depending on the nature of the source data 44

45. Rules management Grabbing rules from others
Watch: hashcat forums, bartavelle, EvilMog
Not all rules are compatible with all suites – see hashcat wiki
Some rules are not GPU-or CPU-ready and will be rejected
Strip CPU or GPU rules with hashcat-utils’ cleanup-rules
Making your own rules
Generate from a given dict and plains list, using bartavelle’s rulesfinder (GitHub)
Deduplicating rules is tricky
space vs non-space, and rules that cancel each other out
0xbsec’s duprule looks promising – still in development
Good rules are better than huge dictionaries.
Grooming your lists of rules is important. 45

46. Attack methods 46

47. Cheat 47

48. Cheat ... Useful only for unsalted hashes
Try Google AND Bing, etc (different results sometimes)
Some specific sites (no specific recommendation - YMMV)
hashcrack.com hash-killer.com/hashdb
md5center.com md5-database.xyz
md5decryption.com md5decrypt.net md5hashing.net
md5.my-addr.com
... etc.
Use sites’ own search features – may not be fully spidered
Sites come and go – scout for new ones
Use a web search for a semi-common hash
You will feel goofy working on a hash for a week only to find out that it’s on Google 48

49. … but cheat responsibly
Consider sensitivity of hashes before submitting – they are stored, analyzed, and being cracking (that is what the sites are really for)
Google/Bing searches may be less likely to expose hashes to third parties (but weigh sensitivity anyway!)
Third-party pentesters/auditors – think hard 49

50. $ ./hcstatgen.bin out.hcstat < infile
Custom Markov
Stock Markov sets are often derived from RockYou (100%!)
This is fine for first passes, but your target may be different
Use your cracks and hcstatgen to build a custom Markov set:
$ ./hcstatgen.bin out.hcstat < infile
… and then use it for bruteforce/mask-based attacks
Example: custom Markov based on LinkedIn founds automatically hits strings with “link” “LI” “linked”, etc. more often and earlier in the attack
Note that modern Markov in password cracking is based not just on character frequency, but on character frequency per position in the string. So it’s very effective. 50

51. PRINCE (1)
PRINCE mode is supported by John natively, and by hashcat as a standalone binary (which you can pipe directly to hashcat)
In essence, it’s a smart combinator attack that will run forever, combining two words, three words, etc. from a given wordlist
Using CPU only and only RockYou as input, early PRINCE testing cracked 72% of LinkedIn in 24 hours – completely automated.
Introductory post from the hashcat forums
Technical details are in slides from atom’s 2014 talk
Note that modern Markov in password cracking is based not just on character frequency, but on character frequency per position in the string. So it’s very effective. 51

52. PRINCE (2)
I personally credit PRINCE for a lot of what I have learned since it was released … because it showed me what I didn’t know yet.
I run PRINCE in parallel with other runs – on CPU, on a separate box, etc.
I also run it as an ‘attack of last resort’ to fall back to when other attacks finish and I don’t have something else queued up.
Use PRINCE. Seriously. 52

53. Broad attack guidance Don’t be afraid to feed things into other things
In epixoip’s Circle City Con class, he described “PRINCEPTION” - feeding PRINCE into itself!
Stdin/stdout and named pipes are key for this exploration
Use the raw numbers to measure performance – was it worth it?
Be ready with bash/Python/perl/PowerShell to try things that don’t have a tool yet (that you know of)
Back up your results(lists, notes, founds, scripts) to reliable media. 53

54. Accurate speed estimation
$ echo -n bsideslv17 | md5sum | awk '{print $1}' >bslv.hash
$ cat bslv.hash
A3c67ba47cfb67c42840acc21a77211f
$ hashcat --speed-only -b -m 0 --quiet --machine-readable 1:0:-1:-1:53.31:
$ hashcat --speed-only -m 0 -a 3 bslv.hash \
?a?a?a?a?a?a?a?a --quiet --machine-readable 1:
Actual speed for this attack is ~17.6% of benchmark speed
Use actual speed to create your attack plans
Benchmark speed will often be different from actual attack speed.
The question is: how different? 54

55. Measuring attack efficiency
“Wall-clock” time efficiency is relative
Crack position (number of guesses) is absolute
Efficiency is relative to capability
Best way to compare efficiency across multiple platforms is position, which is absolute
Hashcat: --output-format that uses ‘crack_pos’
How many guesses did it take to crack this hash? 55

56. Measuring attack efficiency
- [ Outfile Formats ] -
# | Format
===+========
1 | hash[:salt]
2 | plain
3 | hash[:salt]:plain
4 | hex_plain
5 | hash[:salt]:hex_plain
6 | plain:hex_plain
7 | hash[:salt]:plain:hex_plain
8 | crackpos
9 | hash[:salt]:crack_pos
10 | plain:crack_pos
11 | hash[:salt]:plain:crack_pos
12 | hex_plain:crack_pos
13 | hash[:salt]:hex_plain:crack_pos
14 | plain:hex_plain:crack_pos
15 | hash[:salt]:plain:hex_plain:crack_pos
Hashcat: has an --output-format parameter
It sends output to a file of your choice, in a format of your choice.
Select which one that includes the ‘crack_pos’ field 56

57. Measuring attack efficiency
$ hashcat -a 3 -m 0 testmd5.hash ?l?l?l?l?a?a?a \
--outfile test1.out --outfile-format 11 \
--quiet --potfile-path=/dev/null
$ hashcat -a 3 -m 0 testmd5.hash ?l?l?l?l?d?d?d \
--outfile test2.out --outfile-format 11 \
$ cat test1.out test2.out
7e7da6a03ac3b80bad3f338fffa621d5:hash234:
7e7da6a03ac3b80bad3f338fffa621d5:hash234:
The second attack is 100 times faster than the first -
regardless of the underlying hardware speed
* Here we compare two different attacks on the same hash.
* Notice that I’m using /dev/null as my potfile
* Otherwise, previously cracked hashes will be skipped, and I can’t compare the results 57

58. Measuring attack efficiency
Once you have the numbers, plot them (gnuplot, Excel, etc.)
* Notice that the X axis is NUMBER OF GUESSES, not based on wall-clock time. This allow other researchers to compare apples to applies.
Source: Matt Weir (lakiw) PRINCE analysis 58

59. Analyzing cracks and founds
The PACK toolkit is an essential set of tools
Build statistics on letter frequency and mix types
Build lists of masks based on time constraints
Other fantastic features – definitely a minimum 59

60. Working with non-ASCII
If your plains are in one character encoding and your targets are in another, this won’t work
Recommendation: convert everything you get to UTF-8
If your suite doesn’t include encoding conversion tools, use iconv to convert to the target encoding
Looks like John has good support (not checked)
Hashcat recently added encoding-from / encoding-to flags
Hashcat can do multibyte bruteforce with a workaround (RuraPenthe’s)- works, but tricky; his good writeup here
Full example using PACK and German characters: 60

61. Universal attack-plan principles
With inputs, quality and frequency order matter more than quantity
Start simple – crack the easy stuff quickly
If you can cap attack runtime, use it (diminishing Markov returns)
While that is running, analyze plains for untapped patterns
Arrange attacks in order by efficiency for the time allotted
Record all attacks, results, and performance (science!)
Script these and repeat the good attacks on all new founds
Avoid duplicated masks/wordlists - when it makes sense
Append a fallback attack to each attack plan
LET’S PUT TOGETHER SOME OF THESE ELEMENTS
* Start simple with a canned attack plan. Imagine how carpenters work – pondering briefly before selecting the right tool next. Start with hashcat’s default as a base, and expand from there.
* Leverage wetware before hardware. A little thought at the outset can save hours of processing time
* Science it up! You want reproducible results, and to learn from your experiments.
* It’s good to practice how to precisely limit a run, but it’s worth trying to optimize away. (In other words: if you can script it so you don’t have to think about it for future runs, it’s a win; otherwise, don’tbother)
Fallback: Cryptocurrency mining?
I prefer PRINCE 61

62. Understandable naive approaches
“Where can I get more wordlists? I have 120GB so far.”
* Be nice to the noobs. “Moar wordlists!” is actually on the right track, but the wrong concept
* Also understandable because wordlists are the universal input. ALL cracking suites support import of wordlists. It’s natural to want more of them.
* Instead, take the discussion in a more nuanced direction.
** “How can you get quality lists of human-generated strings?”
** “How can you extract base words from these strings?”
** “What are the most effective rules to apply to this wordlist for this target? (and how can you tell?) 62

63. Understandable naive approaches
“I’m trying ?a?a?a?a?a?a?a?a?a?a?a?a?a, what next?”
You should now have an immediate reaction this one. :) 63

64. Understandable naive approaches
3ce8b30b8e25ea5d9a83d4a073d6ddf8
“Ah, this must be MD5 - because it’s 32-character hex.”
* 32-char hex = MD5? Not so fast.
* There is a long tail of weird layering of MD5 and other schemes that look like straight MD5, but aren’t. A particular user of hashes.org (Waffle) has really gone to town on some obscure 32-hex variants
* If there are subtle differences in length or composition, various online and offline tools can make a best guess, but in many cases the only wao to determine what the algorithm is is to guess until you get it right, or get aholf of the source code or reverse engineer a binary.
* Many of the cracking suites support a number of the common variants. 64

65. Understandable naive approaches
“I’m trying to get hashcat to work in Kali, and ...”
* “Moar dicts!” - right idea (“how can I generate more candidate passwords?”), but suboptimal approach – unless you know what you’re doing.
* ?a
* 32-char hex = MD5? Not so fast.
* WPA2 8 chars. If your suite is not rejecting these, file a bug with the author/vendor.
* So far, getting FOSS cracking working on Kali is more trouble than it’s worth. 65

66. Learn from history
Great presentation on the history of password security by Solar Designer and Simon Marechal 66

67. Other bootstrapping resources
Hashcat:
wiki, FAQ, forums, IRC (#hashcat on Freenode), GitHub
John:
john-users mailing list, docs, GitHub for jumbo version
General:
Hashkiller.co.uk and InsidePro forums
Passwords & Ground1234! conference talks on YouTube
PasswordResearch.com (Bruce K. Marshall)
Best password advice I ever got was from Bitweasil, when he told me to join the #hashcat channel on Freenode. 67

68. Cultural hints
Like many geek areas, password crackers can be rough on the noobs sometimes
Information sharing beyond a certain point is limited
Like BSidesLV, related projects are usually “do- ocracies”
Show up, roll up your sleeves, don’t ask the same question twice, and if someone sends you a link in answer to your question, you’d better read it.
The shared common interest makes for a great community
Best password advice I ever got was from Bitweasil, when he told me to join the #hashcat channel on Freenode. 68

69. In other words ... Do not trace the footsteps of the wise;
seek what they sought.
- Bashō (poet, paraphrasing Kūkai (!))
Imitate the intent, not the brush strokes.
- Kūkai (on calligraphy)
[advance: +1]
How many of you have a copy of the wildly successful book “Lose weight slowly through reasonable diet and regular exercise?” 69

70. AlecMuffett curlyboi grempe Matlink sc00bz
Thanks
AlecMuffett curlyboi grempe Matlink sc00bz
Apingis d hashcate ;) mckusick sedition
atom d3ad0ne hydraze Minga simestd
atoponce DaKahuna iphelix mubix solardiz
bartavelle DidierStevens jfoug neheb soxrok2212
bill_e_ghote digininja Jumpforce NETMUX stanev
Bitweasil doc2n ken nitrxgen stratomarco
blandyuk DoZ kholia _NSAKEY Szul
bmenrigh dropdeadfu kmalvoni nuartvision T0XlC
brutemorse empty_knapsack Kryczek NullMode thorsheim
cantcomputer epixoip kwzh philsmd undeath
Chick3nman ErrataRob lakiw PwdRsch unix-ninja
claudioandré EvilMog lars r4d1x veorq
coolbry Fist0urs lyosha richrumble waffle
CormacHerley floyd m33x Rjmendez winxp5421
countuponsec frank-dittrich m3g9tr0n Rolf Xanadrel
cowboym g0tmilk m8urnett rurapenthe xmisery
cperciva GiftsUngiven magnum ryan-c ZerBea
CrackTheHash gm4tr1x mangix s3in!c zorinaq
Contact:
Slides, errata, references: 70