Ep 3: Creating bespoke wordlists and cracking a hash!

Welcome to Episode 3 of this learning stuff series. If you’ve missed them Episode 1 involved the building of a lab and Episode 2 looked at SMB and using responder to capture a hash.

This episode we will take a look at creating a bespoke wordlist using a tool called Cewl and trying to crack the hash we captured in Episode 2 using JohnTheRipper and Hashcat.

As always with this series, there is a video available here: https://youtu.be/vK51T3NwzPw (where this week, we learn that I should not try to speak other languages!)

A reminder that my lab is all set up as a Dr Who theme, with TheDoctor as a Server 2019 Domain Controller, TheMaster as a Win10 domain joined machine and Torchwood as my Kali box. All users within the lab also follow the theme, with Clara as a domain admin and Rose as a domain user.

What do we have?

So from the last episode we got a hash from responder

Copying these hashes, I’ve put them into a text file that we can feed into the cracking tools later on.

Before we can crack these, we need to create a wordlist. There are a bunch of huge wordlists that we could try, such as RockYou which is built into Kali or any of the SecList popular passwords. These would be a go to on a real engagement where people have used standard passwords. However the password for Rose isn’t in Rockyou (I checked) and I doubt it’s in the SecList’s lists.

As the lab is all Dr Who themed, it would be a safe assumption that the password will follow that theme, so creating a bespoke wordlist would make sense.

**Note: This fucked up once. Fixing with an actual crackable password**

Note: I actually ran through this entire blog with the password we set in Episode 1, however this ended up not being in the wordlist, so therefore didn’t crack! So before we go through this, let’s change the password and re-capture the hash.

Opening up a command shell as admin

net user /domain Rose *Redacted*

Then we need to start responder again

sudo responder -I eth0 -v

Visiting a fake share then provides a new hash! That then get’s added to the responderhashes.txt file.

**End Note**

Using Cewl

To do this there is a tool created by Robin Wood called Cewl, this is pre-built into Kali or is available on GitHub.

When creating a bespoke wordlist, we have to think about the source of the wordlist, where would be a good place. For a business it could be their website, but for this lab, I think 2 wikipedia pages will be the most beneficial:


So these will be our targets. Looking at the help for Cewl there are a few options available to us:

Some of these options are great, the option to Spider a website and bring back all pages is brilliant for business pages, but might not be a good idea on Wikipedia! There is also the minimum word lengths, which allows us to skip any low character words, so ignoring all “a, an, on, in” type words that are unlikely to be a password. It can even do authentication agaisnt a website which is brilliant for those restricted pages!

For our purposes, we will use 0 depth and a minimum word length of 3 for the sites. I also want to write the output to the file, so will include the -w flag.

The tool can only deal with 1 URL at a time, so the 2 commands were run:

cewl -d 0 -m 3 -w Doctor_Who.txt https://en.wikipedia.org/wiki/Doctor_Who
cewl -d 0 -m 3 -w Rose_Tyler.txt https://en.wikipedia.org/wiki/Rose_Tyler

The tool runs unbelievably quickly and produces an file with the wordlists in. A quick wordcount shows that the Doctor_Who output has 5,494 words and the Rose_Tyler has 2,809 words! Madness!

The tool also removes any duplicate words, so you are left with a wordlist full of unique words, taking a look through the wordlist we have a whole range of words, some of which could plausibly be the password.

However,we still have two wordlists. We can combine these using cat and then sort them by uniqueness. This leaves us with a wordlist of 6,652 words.

cat Doctor_Who.txt > Passwordlist.txt
cat Rose_Tyler.txt >> Passwordlist.txt
sort -u Passwordlist.txt > Unique_Passwordlist.txt

There is a problem with this wordlist though. It is only words with upper and lower cases, to improve password security it’s likely that the user has added in some symbols, done some leet speak or added some trailing numbers, so we need to run this list through some rules to create variations of each word.

Using rules for a better password list

Within the JohnTheRipper tool there is an option for mangling wordlists with rules. There are some built in rulesets which will add in various different items to the wordlist. For more options on the John rules, I found an excellent cheatsheet.

This can be used directly when cracking, but ideally we want a new file so we can see what the rules command has really done.

The command needed for this is:

john --wordlist=Unique_Passwordlist.txt --rules=single -stdout > Rules-wordlist.txt

The wordlist is the passwordlist we created earlier using cewl. We then want to use the single ruleset which will add in some additional data to the wordlist.

This level of mangling allows this to finish quite quickly, and gives a much bigger list, with over 5 million words now!

Doing a grep for Cybermen now brings back 287 results!! This has all extra letters and numbers before and after the word.

I did try running all rules and it took over an hour and had 406million entries which is bonkers!

Now that we have the extended wordlist, we can run this through John and Hashcat to try and crack the password!

Cracking the Hash

There are a number of different programs that can be used to crack hashes but the two most popular are JohnTheRipper and Hashcat, both of which are pre-installed on Kali.

I find John easier as it looks at the hash and works out the format for us, so it’s the easier way. The crackers can do pure bruteforcing, so going through characters, set to a mask or to a certain amount of characters, however another option and the one we will use is to use a wordlist which the cracker will run through and see if the hash matches.

John The Ripper

The syntax we need for this is:

john --wordlist=Rules-wordlist.txt responderhashes.txt

This will then identify the hashes and try to crack them. I left previous hashes from the old password in the file, so there were 3 different hashes available for John to try and crack.

Full success! It cracked the password, which was Rose’s other half with a number after to ensure that higher level of security! (You’ll notice that the previous password did not crack, as the wordlist mangling didn’t do as much to get that password)

With John, if there are a whole load of passwords, you can also show the cracked passwords from a file. This is a really easy syntax:

john --show responderhashes.txt

This shows the username, password and the hash for all cracked credentials.


I find hashcat slightly less intuitive but it is just as powerful as john, so we can use the same details, the hashes and the wordlist, however hashcat doesn’t identify the type of hash, so we have to find that out. It’s available within the help:

hashcat -h | grep NTLM

This returns all the NTLM options:

I think we want to use NetNTLMv2, so hashtype 5600. We also need to set the attack mode to straight (0) and output file for cracked passwords, then the hashes file and the wordlist. Due to this being on a VM we then need to run –force as it doesn’t have a GPU to use. Our final command looks like:

hashcat -m 5600 -a 0 -o cracked-password.txt responderhashes.txt Rules-wordlist.txt --force

This then runs through the wordlist until it’s exhausted or all hashes are cracked.

We can see that the status was exhausted meaning it went through the entire wordlist and could recover 1/3 of the passwords. We can also see that this only look 22 seconds which is crazy fast!

As we set an outfile, we can cat that file to get the cracked password.

Similar to john, this gives us the username, the hash and the cracked password!


So once we have some hashes, it is super straight forward to create a bespoke wordlist and run the hash through crackers. I’d expect in a big environment the passwords wouldn’t be too complicated and standard mixed with bespoke wordlists will be able to crack a large amount.

As we now have a set of credentials, in the next episode we will look at tools that we can use with them. I’ll take a look at smbclient, crackmapexec and will do more videos to look at running Bloodhound on the domain to see what we can find out!

If there is anything you’d like me to look at or explain, feel free to let me know on twitter!


Ep 2: Understanding Responder

This is epsiode 2 of my Learning stuff series. If you missed Episode 1: Building a lab you can find the video here and the blog here!

There as always is a video that goes along with this blog, which can be found on youtube here: https://youtu.be/7wSXxxotmFc (This time we learn that I cannot elegantly shuffle playing cards!)

Now that we have our Lab set up, we are going to start doing some attacks and understanding how they work. Today we are going to look at the tool responder.

Between the videos I also set up a kali box which I will use for attacking. This box has been named “Torchwood” as it’s my support box that is always there when I need it!

Setting up RDP

However before that, I wanted to get RDP access enabled on the boxes, so that I can do the videos in fullscreen as vmware tools was being a dick. As with building the lab I’ve tried to make this as easy as possible so I’ve written some powershell.

These need to be run on both TheDoctor and TheMaster. I’m sure it could be done by group policy however with only 2 machines, this is an easier method for now.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member Clara, Rose

Then we need to enable RDP and allow the remote desktop policy via the firewall.

Set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\‘ -Name “fDenyTSConnections” -Value 0
Set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\‘ -Name “UserAuthentication” -Value 1
Enable-NetFirewallRule -DisplayGroup “Remote Desktop”

Perfect, now we can RDP into both machines making life slightly easier.

Configuring Shared Folder

For responder to work, we need to have a shared folder that we try to access over SMB. To create a shared folder, you guessed it, we have some powershell.

We are going to have a folder on TheDoctor and access it from TheMaster. Then we will put responder in the way to see what happens.

On the Domain Controller, logged in as Clara (DA) this powershell will create a folder called Timelords in the C:\ drive and share it with the user Rose.

New-Item -Path "C:\" -Name "Timelords" -ItemType "directory"
New-SMBShare –Name “Timelords” –Path “C:\Timelords” –FullAccess tardis\rose

If you want to remove the share for any reason, this can also be done via Powershell

Remove-SMBShare –Name “Timelords”

So now that we have a shared folder, we can look at connecting to it from TheMaster.

Logging onto TheMaster as Rose, we navigate to \\TheDoctor\Timelords, this let’s us see the connection works and the files are there.


Now to understand how this all works I’ve downloaded Wireshark on both machines and we can track the traffic to see what happens.

Understanding SMB

Wireshark is super powerful and has lots of filters that we can apply to get the data that we want. First up, we want to only look at the traffic between TheDoctor and TheMaster, we do this by adding a filter

ip.addr == and ip.addr ==

This has now restricted the output that we see.

As you can see, there is a lot of information with Windows background stuffs that happens. Some KRB5 which is the kerbose tickets and some TCP and DNS traffic. However in the middle, there are 4 lines for SMB and SMB2. This is what we are interested in.

It’s possible to look at that and follow the stream, so all the data that is related to that. To do that, right click on the line and go “Follow” -> “TCP Stream”

Now we can see that this stream is the SMB traffic we want. It’s filtered on stream 13, it’s likely your number will be different.

This now shows only the packets that are used within this transaction. The ones we are interested are quite near the top:

I’ve highlighted the key areas in red. At the start the SMB specific protocol is negotiated between the machines. Ending on using SMB2!

Then a session is requested and setup successfully.

TheMaster then requests the actual directory \Timelords. I think due to the lack of second leading “\” an error is returned in form of a 404.

Then finally, TheMaster requests the correct directory which is in the form of a request tree. This is then granted by TheDoctor.

Once that has been complete, TheMaster then makes a request for all the files in the directory which TheDoctor sends back. These can be seen through these packets:

This process has given all the information needed between the two hosts.

This interaction has used SMB2, however there are 2 other versions available.

There is the older SMB1 that became well known with the EternalBlue vulnerability (MS17-010) which allowed the WannaCry malware to spread. This protocol allowed for certain pipes to be exploited resulting in variety of attacks including reverse shells. To check if your machines still have SMB1 enabled, there are Powershell one-liners:

For Windows 7/Server 2k8(R2)/Vista

Get-Item HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object {Get-ItemProperty $_.pspath}

(Default configuration = Enabled (No registry key is created), so no SMB1 value will be returned)

For Windows 8/Server 2012

Get-SmbServerConfiguration | Select EnableSMB1Protocol

For Windows 10:

Get-WindowsOptionalFeature –Online –FeatureName SMB1Protocol

For Server 2016/2019:

Get-WindowsFeature FS-SMB1

The step up to SMB3 increases the encryption complexity as well as various performance and availability upgrade. Full details of the versions can be found on this microsoft doc.

Also with SMB it is possible for shares to be configured to allow anonymous access, this is a quick win for an attacker if it’s enabled. To double check we can use our Kali box, Torchwood, using a tool called smbclient we can attempt to list the available shares from TheDoctor as an anonymous user.

smbclient -L -U anonymous

In this case, anonymous access hasn’t been selected on the share, which is for the best!

(We may come back to smbclient once we have a password!)

Exploring Responder

Responder should be installed on Kali as default. If not it’s possible to download it from the lgandx Github page.

What this tool does, is intercepts that request for an SMB share, stating that it is that share. Therefore the client sends over the password hash to authenticate and check access. This hash is then captured and might be crackable.

Looking at responder’s help file, there is a lot of different options which are available.

What we are interested in doing, is setting responder on our external interface in verbose mode. What we want to avoid is breaking anything, so we don’t want the -r function or the WPAD server.

sudo responder -I eth0 -v

This then runs and shows all the servers it is pretending to be. Really we are only interested in the smb server.

Before accessing the share, we are going to get Wireshark going again on all boxes, so we can see what happens differently now that Responder is in the way!

Interestingly, when visiting the share (which i’d already visited for the stuff above) responder saw some details:

It however, didn’t capture a hash, it just did some poisoning.

However on TheMaster I was able to see the folder without an issue. This would indicate as I had already visited the share, I also had been authenticated to the DC via a Kerberose golden ticket so an additional authentication request wasn’t required.Also it’s likely that TheMaster had the DNS record of where that file was so didn’t need to “look” for it on the network.  Looking at the Wireshark output similar to the previous requests was done.

To try and understand this a little more, I restarted TheMaster and cleared the DNS with some powershell:


Now TheMaster shouldn’t know where the sharedfolder is stored, so may make more requests. However it was able to find TheDoctor and the share without any issue.

Capturing Hashes through fake shares

Looking online, a lot of articles mention visiting shares and computers that don’t exist. So if we try to visit


We might be able to replicate the searching that would happen on a network.

If we don’t have responder running, we can see these requests in the Wireshark output:

We can see that there are requests made via DNS, with responses coming back as “No such name”, so in effect 404 errors. Then once the DNS has failed, Windows moves onto the MDNS protocol and finally LLMNR.

All of these requests fail and is basically TheMaster shouting into the void.

This is now perfect ground for Responder, as it can pretend to be \\DALEK\DALEK and get the NTLM hash from the user.

Running Responder on Torchwood:

sudo responder -I eth0

Then on TheMaster we re-try to access \\DALEK\DALEK. This time responder poisons the answer sent back to confirm that it is that share. We can see this in the wireshark output:

What we can see is that the same requests are made, firstly by DNS which isn’t found anywhere. Then the MDNS request is made, where Responder on Torchwood ( broadcasts an arp request to find out where the send the repsonse, then replies saying that it is that share.

This success message is then sent back to TheMaster. This then kicks off a similar transaction to what we saw before. However, due to the machine not being pre-connected via the Domain. It makes a request for NTLM_SSP CHALLENGE back to TheMaster.

This is then responded with the NTLMSSP_AUTH for the user TARDIS\rose and this is the hash that we are interested in.

From Responder, the output that you will see is similar to below. It shows that it has poisoned the MDNS request, then get’s the NTLMv2-SSP details including the hash!

This is great, we have requested the auth and it’s been provided in the form of the hash. Success!

Interestingly if you run Responder with the -v (verbose) flag, it shows each of the hashes and they have varying salts and results, meaning you get a large amount of different hashes.

The user who tried to visit the share, then receives a sign-in popup box:

If the user puts in their credentials, they receive an “Access is denied.” message

If you want to keep testing with Responder and want to re-capture hashes, you need to clear the cache which is in the Responder database:

sudo rm /usr/share/responder/Responder.db

So this is great, we got our hash. So what happened that was different to before? Well this time TheMaster didn’t know the location of Dalek, so it sent out requests to try and find it, it also wasn’t already authenticated via Kerborose tickets so it needed to do the entire NTLM_SSP auth process again, which is what provided the hash.

Using Responder in the real world

However, in an environment which uses Group Policy to push down mapped drives onto the users machines, they never type in the paths, so wouldn’t ever have a reason to enter in the wrong machine name.

In a large network, like most companies would have, the DNS, MDNS and LLMNR requests would be made, to find the share and if responder sits in between the source and destination of the request and the actual server, it will pretend to be the server with that share.

Once it has poisoned that request, it will do the same exchange as we saw with the \\Dalek\Dalek share and request the NTLM_SSP Auth as the fileshare isn’t likely to be on a Domain Controller so would not already be authenticated via a golden ticket, this would then result in a hash being provided.

However, if the request finds the actual server first, this is then cached within the DNS cache on the machine, resulting in all future requests knowing exactly where to go, skipping any chance of responder working. All you’d have left is to hope someone mistypes in the fileshare path and you can claim that hash!

It’s important to remember that when this tool is running, end users cannot access the fileshare. So if you leave it on for an hour, a user might not be able to access files for that entire hour. This can be really bad news, especially if its a Monday morning and they have an important presentation or similar!

Although not a full success in the lab environment, this tool can still be powerful in the real world and is worth running, but it’s worth running before those DNS cache’s have been created, so at the start of the day as people as logging on, or after lunch when they have been away for a while. It’s not impossible that you won’t catch any hashes, but it’s always worth a shot!

Let’s pretend….

Seeing as how this series is all about learning things. Let’s pretend that last part worked, and like we did when an incorrect filepath was entered, we captured a hash. What can we do with it now? Well seeing as how everything in this domain is Dr Who related, I think the password might also be related, so in Episode 3 we will look at using tools to create bespoke wordlists, finding out about rules and hopefully cracking the hash!

Hopefully this blog was useful in showing how SMB works at a low level and how responder can sit in the middle and pretend to be the server to get some hashes. As responder has many more functions that just SMB, I’ll try and take a look at the other options in another Episode further on in the series.