DLL Hijacking

What is DLL Hijacking?

Actually before we get onto what DLL hijacking is, let’s go back a step

What is a DLL?

A DLL is a “dynamic link library” and is used within Windows. It’s a library which contains code and data which can be used by many different applications. So rather than each application coding the same function, a DLL can be called to do it instead!

DLL Search Order Hijacking

The way that DLLs work, is that the program will request the DLL, it has a specific search order (which can be important!) if the DLL isn’t fully referenced.

For example, say the program Origin (the EA game store) installed in D:\Origin\ asked for DLL “test.dll”, the search order would be:

  • The directory which the application loaded (D:\Origin\test.dll)
  • The system directory (I think that’s C:\Windows\System32\test.dll – but not 100%)
  • The 16-bit system directory (I think that’s C:\Windows\System\test.dll)
  • The Windows directory (I think that’s either C:\Windows\System32\test.dll or C:\Windows\SysWOW64\test.dll – but not 100%)
  • The current directory (I guess where ever the shortcut is? Maybe C:\Users\Phil\Desktop\test.dll)
  • The directories that are listed in the PATH environment variable

This has been taken from the MS docs here and they don’t make it overly clear!

Normally, a DLL would be fully referenced, so if it’s in System32, the reference to the DLL will be “C:\Windows\System32\test.dll”. If it isn’t fully referenced, we could put a malicious DLL into the application folder, which would be loaded.

This method is part of the MITRE ATT&CK framework.

Searching for Non-Existant DLLs

Rather than looking for the search order and trying to abuse that. For this blog, we are going to look for DLLs that don’t exist but are requested by programs and place our own malicious DLL in the location requested, and see what happens.

To do this search, I’ve used procmon  which is part of the Sysinternals suite of software and readily available for download.

After downloading the app, run it and you will see a whole bunch of information on all running programs.

Once that’s running, I booted up Origin and saw that it made a whole bunch of requests.

There is so much information, that it is impossible to go through it all! However, we can filter by .dll.

Go to “Filter -> Filter” (or press Ctrl+L) and we need to add in a path search that contains dll

Click Add, then Ok and we see the list is a now a lot shorter! If interested in a specific program, you can filter on this as well to make the list much more manageable.

Now we have a shorter list, We can see the result has a few different options. One of which is “Buffer Overflow”, I have no idea what this is, but for me right now, more interesting is the “NAME NOT FOUND”. This means that the DLL doesn’t exist.

If we go to the folder, we can confirm that, as it should be between L and O. Thanks alphabet!

What does this mean though? What this means is everytime Origin is launched, it looks for a DLL that isn’t there. So if it was there, it would look for it, find it and execute whatever code was in it.

Creating malicious DLL

Luckily for us, creating a malicious DLL isn’t too difficult. The real challenge is getting it past Windows Defender and other anti-virus.
However, for this example, we are just going to pop a local command prompt. It is possible to do reverse shells, migrate payloads, load in a colbalt strike beacon or C2 droplet or literally anything else you could do with a computer!

So for this we are going to use msfvenom with the following:

msfvenom -f dll -p windows/exec CMD="C:\windows\system32\cmd.exe" -o shell32.dll

This runs through and creates a DLL

We don’t want it to be called shell32.dll however. We need it to be “midimap.dll”. A quick mv get’s the file as we want it.

Now that we have our malicious(ish) DLL, we need to move that over to our target.

I have spun up a VM for this, with Origin installed on it, so the path is now C:\Origin\

Using a SimpleHTTPServer and a web browser, I can directly download the new DLL onto the Windows VM

Saving it directly into C:\Origin\

However, not unexpected but the dll is flagged by Defender and removed immediately.

Well bugger, ok. For this PoC if I log in as Admin I can allow the file through!

After allowing the file, redownloading it stops it from being removed by Defender.

Running Origin

Now that’s there. Origin should call that DLL which will pop a cmd box.

There we have it, a command prompt opened as we can see the Origin process called that midimap.dll a number of times.

However, the shell is the same low privilege user that I am logged in as. So this isn’t a priv esc 0day in Origin, it’s just exploring DLLs!

What’s next?

So what’s next for this attack and our research, well there are 2 main things:

  • Finding DLLs that run as privileged users

Although this attack is fun and looks cool, it hasn’t gained us anything. We would just have a shell as the user logged in, what we really want from this is priv esc. So searching for those DLLs that get called as an admin user would gain so much more!

  • Writing payloads to avoid AV

The second useless part of this attack in it’s current form, is I needed to use admin creds to allow the payload onto the machine. If you could do this, then there is no point in the attack, as you’d have the admin creds! So writing bespoke programs that avoid AV detection is also a really important area to look into!

It might also be worth looking for programs where you can abuse the search order. Finding DLL’s that haven’t been properly references, although I have no idea how you would do this!

Ep 4: Using smbclient to view SMB shares

Welcome to Episode 4 of my Learn stuff series. You’ll remember that in Episode 3 we managed to crack the hash that we captured using responder in Episode 2. This now means that we have a username and password combination.

This is great! But, in an engagement what are the next steps? What can we do with this and ideally what are we looking for?

As always with this series, there is a video which goes through the same steps, this is available here: https://youtu.be/5XkwDsCrBig

What do we have?

Well in the last episode we managed to crack the hash using both JohnTheRipper and Hashcat using a bespoke wordlist we created with Cewl.

This  means that we now have credentials for a user on the domain:

Username: Tardis\Rose
Password: Mickey1

Where next?

So, what can we do with that? This is where the tool smbclient comes into play. This tool is built into Kali and let’s us use our Kali instance to try and connect to SMB shares. This are often known to end users as “Z drive” or similar.

They are a central repository for files that are hosted on a physical machine on the network. Often most users will have access to the share’s although some may be restricted based on security groups within Active Directory, keeping really sensitive data private e.g CEO e-mail backup!


Often within CTFs when looking at SMB it’s when hunting for a password, or a database that contains a password, but in the real world this might not be the most juicy of targets. Sure a password might get you into another system, but it’s likely all the information you need is within these shared files.

So what should you be looking for?

  • Clients lists
  • HR documentation (Hiring/Firing/Disciplinary action)
  • Salary details
  • Business plans – buy outs, major inventions etc
  • Financial records

All of these could have a bigger impact for a company than just a password for another system. Think of the damage an attacker could do if they got a list of everyone the company had fired, or the stock market implications if a buy-out was about to happen.

If an attacker got a full client list with details, they could then use this information to perform phishing attacks on other companies with an almost guaranteed in!

All of these are highly sensitive data that could have huge ramifications for a company. If you are doing a real-world engagement, these are the things that need to be fed back.

What else?

Well, if you have write permissions, which is likely, you could put a file onto the share. Something named “2019-2020 salary details.xlsm” would be enticing for anyone to click on. The embedded macro (who noticed it was .xlsm?) could then pop a reverse shell, or make a request to our SMB share to capture more credentials or a range of other attacks that would further our foothold in the network.

So how does it work?

Well first up, we have TheDoctor with some shared drives on it.

These files are accessible to users within the domain that have the correct level of access!

So from Torchwood it’s now possible to use SMBClient to gain access to those files. SMBClient can check for anonymous access, which is widely used within CTFs:

smbclient -L \\ -U anonymous

However in this instance, the shares require authentication against the server. This is the default settings within Server 2016 & 2019 , so finding anonymous shares is going to be become a rarity outside of CTFs.

For SMBClient there always needs to be double the amount of backslashes, this is due to the backslash being the escape character in python, so you have to escape the escape for it to work! If your command doesn’t work, check the number of backslashes.

Next up, we can use the credentials that we have. The W flag is for the workgroup, in this case the TARDIS domain and the U flag is for the username.

smbclient -L \\ -W TARDIS -U Rose

We can see that there are a few different shares available to us, but note that not all shares are available:

For example the user Rose doesn’t have access to the “Dalek Database” or “Gallifray”. This means that it might be required to compromise another user to gain further access!

However, we do have some shares that are available and we can access them using:

smbclient \\\\\\Companions -W TARDIS -U Rose

It’s also possible to download all the files onto the local machine using the get command, allowing for offline searching at later time.

Looking at the wireshark traffic for this, it looks very similar to a legitimate SMB request, so it would be difficult for a sysadmin to find within the logs.

It’s also possible that the user has write access to the share. This can allow malicious files to be uploaded, or if there is LFI within a web application your own code can be run, which again is a CTF favourite.

We can upload files using the put command:

put HowtheTardisWorks.txt

That’s all folks!

This is a really effective tool, with the traffic looking like real requests in an area that there is generally a lot of traffic doing similar. This allows hunting for those sensitive files with potential for company secrets, additional phishing material or passwords for more systems!

The only problem is you may not know where the shared files are stored and that’s where a tool called CrackMapExec (CME) comes in to play! On the next Episode I’ll take a look at using CME to hunt for SMB shares and using the credentials for further access!




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.




Ep 1: Creating a Active Directory Virtual Lab


This is quite exciting for me, this is Episode 1 in my official Learning Stuff series with the tagline: “Knowing stuff is cool, learning just takes longer”.

The video that accompanies this blog is available here: https://youtu.be/ZKrkkUlssAE

This series is going to go through a set of different attack, defence and general pentesting theories and practicals. The idea is hopefully I can explain things to you in a way that helps, maybe that others haven’t. We shall see!

So first up, before we can do anything specific, we need to build a lab! For this I’m using an ESXi host that I have access too, however the same thing can be achieved by using VMWare on your own machine.

Setting up Lab

I ideally wanted to build the lab using Packer/Terraform/Vagrant however after many hours of trying I always ended up failing, so I’ve parked that for now until I get more time. Hopefully in the future I’ll have a blog about that sort of automation. However for the moment, I am just going to spin up boxes the old fashioned way, however I’ve got a whole bunch of powershell to make it slightly easier.

The hardest bit is choosing the domain, computer and user names. But I always like to theme things, so for this I’ve gone down the Dr Who route! What my lab will consist of for this video is:

1x Windows Server 2019 - TheDoctor

1x Windows 10 - TheMaster

Domain Name: tardis.local

User 1 (Regular user) - Rose Tyler (rose@tardis.local)

User 2 (Domain Admin) - Clara Oswald (clara@tardis.local)

Firstly go through the normal Windows set up:

Once both the Server and Win10 machines are booted. We need to set up a few little things. This powershell script will set the Hostnames and IP addresses which will allow the connectivity we need.  On the lab I’m using, there is DHCP set-up so I don’t have to set up the IP manually, but I’ve left it into the powershell script for you to use, obviously change the variables to suit your lab.

If you haven’t set up Active Directory before or a lab at all, and want to do it without Powershell, my friend myexploit2600 has written an excellent step-by-step guide.

First up we need to configure the Server and add Active Directory. After that we can sort the Win10 machine.

Windows Server 2019

Setting IP and Hostname

$Interface = "Ethernet0"
$IPAddress = ""
$DefaultGateway = ""
$Hostname = "TheDoctor"
New-NetIPAddress –InterfaceAlias $Interface –IPAddress $IPAddress –PrefixLength 24 -DefaultGateway $DefaultGateway
Set-DnsClientServerAddress -InterfaceAlias $Interface -ServerAddresses $IPAddress
Rename-Computer -NewName $Hostname

The machine will then re-boot so these changes have taken affect. Re-log into the Server.

Once we have the correct hostname and network connectivity, we can covert this server into a Domain Controller. It should be noted that this isn’t relevant for this lab specifically and with running responder it’s possible without. However I’m going to use this lab in the future, hopefully looking at some domain based attacks, so I might as well set it up right from the off.

To change the server to a Domain Controller, we need to install the Active Directory modules, again this Powershell script should do it all for you. Just change the domain variables at the top.

Setting up Domain Controller

$DomainName = "tardis.local"
$DomainNetbiosName = "TARDIS"
$SafeModePassword = "!S0n1cScr3dr1v3r1" | ConvertTo-SecureString -AsPlainText -Force

Install-PackageProvider -Name NuGet -MinimumVersion -Force
Install-WindowsFeature AD-Domain-Services 
Import-Module ADDSDeployment 
Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath “C:\Windows\NTDS” -DomainMode Win2012R2 -DomainName $DomainName -DomainNetbiosName $DomainNetbiosName -ForestMode Win2012R2 -InstallDns:$true -LogPath “C:\Windows\NTDS” -NoRebootOnCompletion:$true -SysvolPath “C:\Windows\SYSVOL” -Force:$true 
Install-Module ServerManager 
Add-WindowsFeature RSAT-AD-Tools

This again will reboot, log back in and we now have a domain up and running!

Now all the domain needs is some users. Again I like to stick with a theme! Change the variables to suit your own environment (I know not everyone will want a Dr Who based Domain)

Adding Users

$OUPath = "DC=tardis,DC=local"
$DomainUserPath = "OU=Domain Users,DC=tardis,DC=local"
$DomainAdminPath = "OU=Domain Admins,DC=tardis,DC=local"
$User1Name = "Rose"
$User1GivenName = "Rose"
$User1Surname = "Tyler"
$User1SAMAccount = "rose"
$User1PrincipalName = "rose@tardis.local"
$User1Password = "B4dW0lf" | ConvertTo-SecureString -asPlainText -Force
$User2Name = "Clara"
$User2GivenName = "Clara"
$User2Surname = "Oswald"
$User2SAMAccount = "Clara"
$User2PrincipalName = "clara@tardis.local"
$User2Password = "Imp0ss1ble!" | ConvertTo-SecureString -asPlainText -Force

New-ADOrganizationalUnit -Name "Domain Users" -Path $OUPath -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Domain Admins" -Path $OUPath -ProtectedFromAccidentalDeletion $true
New-ADUser -Name $User1Name -GivenName $User1GivenName -Surname $User1Surname -SamAccountName $User1SAMAccount -UserPrincipalName $User1PrincipalName -Path $DomainUserPath -AccountPassword $User1Password -Enabled $true -ChangePasswordAtLogon $false -PasswordNeverExpires $true
New-ADUser -Name $User2Name -GivenName $User2GivenName -Surname $User2Surname -SamAccountName $User2SAMAccount -UserPrincipalName $User2PrincipalName -Path $DomainAdminPath -AccountPassword $User2Password -Enabled $true -ChangePasswordAtLogon $false -PasswordNeverExpires $true
Add-ADGroupMember -Identity "Domain Admins" -Members Clara
If lots more users are required, it’s worth creating a spreadsheet or similar with the information and importing it, as I’m only currently adding 2 users (one user and one admin) I’ve just put it all in variables.
To check that the users have been added, it’s worth looking in “users and computers” to check the OUs and Users are where they should be.
This script also then elevates Clara to a Domain Admin by joining her to the DA group. This will allow that user to add other computers to the domain and other privileged rights.
A good tip with Users and Computers is to enable “Advanced Features” by going to View -> Advanced Features. This then gives more property options on each OU and users.
Once that is done, we have a Domain set up with some users, with different permission levels. At a later stage, I’ll set up some group policies and other hardening bits and pieces but these aren’t required for the moment.

Windows 10

Let’s now turn our attention to the Win 10 box.
We firstly need to set the hostname and the IP address as we did before. However on the Windows 10 box, before we can run scripts, we need to set the Powershell bypass policy, this will allow any scripts to run. This is a really bad idea in corporate environments, but is fine for our private lab.
set-executionpolicy unrestricted

Setting IP and Hostname

$Interface = "Ethernet0"
$IPAddress = ""
$DCIPAddress = ""
$DefaultGateway = ""
$Hostname = "TheMaster"
New-NetIPAddress –InterfaceAlias $Interface –IPv4Address $IPAddress –PrefixLength 24 -DefaultGateway $DefaultGateway
Set-DnsClientServerAddress -InterfaceAlias $Interface -ServerAddresses $DCIPAddress
Rename-Computer -NewName $Hostname

Once that is configured, we need to join the machine to the domain. This will make that connection to give access and be able to log in using the domain user and admin that we created earlier.

Adding machine to domain

$domain = "tardis.local"
$password = "Imp0ss1ble!" | ConvertTo-SecureString -asPlainText -Force
$username = "$domain\Clara"
$credential = New-Object System.Management.Automation.PSCredential($username,$password)
Add-Computer -DomainName $domain -Credential $credential
Now that’s done. We can log back into the machine with the domain creds that we set up earlier on TheDoctor.
What we also need on this network, is a Kali Linux box for doing the attacks from. I’m not going to go through how to set up Kali but hopefully it’s easy enough.
For a lot of the attacks, it will be interesting to see what’s happening on all machines. So I’m going to download and install Wireshark on all machines.

That’s it, we now have our lab set up. It’s bound to grow and evolve over the course of this series, but this is a good place to start!

Next Step!

Next up in Chapter 2 I will look at responder, starting with setting up shared folders, creating a regular task to check the share and capturing some hashes. I’ll also do a deep(ish) dive into the traffic going across the network using Wireshark.

If there are any other attacks you’d like to see me do and explain. Please let me know on twitter.

Hope you enjoyed this and keep learning!!