Searching for password files in PowerShell.

Searching for files in PowerShell, more specifically potential password files. During the course of a pentest once you have compromised a windows host there is a good chance that you will want to enumerate the box further to gather as much info as possible. This will most likely include searching the local system for passwords. We can use the following syntax in PowerShell to search for files with the text ‘password’ in the filename, just like below. We use the wildcard ‘*’ either end of the ‘passwords’ so we can search for variations in the file name.

Searching for files in powershell

Simple and quick!


Conducting a PowerShell Port Scan

How to conduct a PowerShell Port Scan. Using PowerShell to conduct a simple port scan is very useful. If you have compromised a Windows server on a pentest and want to conduct a quick port scan you can use PowerShell. This might be to verify open ports on a neighboring system or to check egress filtering outbound to the internet using a public IP.

Using this simple one liner will produce a port scan of all ports 1-65536, the code snippet will also ask you for the IP address you want to port scan. Of course you can swap out the port range or simply substitute the ‘1..65536’ for something shorter like ’80, 445, 3389′ just like in the second example:

And in action this looks like the below:

PowerShell Port Scan

PowerShell Port Scan


PowerShell Ping Sweep

How to conduct a PowerShell Ping Sweep. So you have just pivoted into a new subnet, compromised a Windows Server and want a quick ping sweep of the subnet to see how many targets are in the range. Why not use PowerShell. This is pretty straightforward, we can use the following syntax to perform a ping sweep of a /24 subnet:

This should look like this in action:

PowerShell Ping Sweep


Pivoting with netsh in Windows!

Just a quick post to demonstrating pivoting with netsh in Windows! More specifically port forwarding with netsh in Windows (Windows 7 and above). This really is great as your not having to upload any tools to the target system. It is limited in its functionality however is a great option for say a single port such as 445 or 3389.

Now if you don’t have interactive logon rights but you have a PSEXEC, PTH or even a meterpreter session you can add a port forward on you target system and pivot to your next target with SMB/445. This is especially great when you think of tools like PSEXEC module in Metasploit or the main other remote CMD tools available. Now you could use the autoroute or route add function in Metasploit but its nice to have a backup plan if you didn’t have Metasploit!

You can use the below to display your port forwarding rules:

Just remember to clear down your port forwarding rules when your finished with:



VLAN tagging in Kali Linux 2.0

Just a quick post on how to configure VLAN tagging in Kali Linux 2.0. If we have a trunk port presented to us, how do we utilise it?

To setup vlan tagging in Kali Linux 2.0 is pretty straight forward, to set the scene and demonstrate this further we need a lab. The below lab is our ‘test.local’ environment set up in GNS3. There are 3 vlans, 10 20 and 30. 10 and 20 are routable, vlan 30 is isolated from 10 and 20. In the lab we have a ‘router on stick’ configured  at R4, fa0/1 is sub interfaced with vlans 10 and 20. utilising DHCP, vlan 10 for servers and vlan 20 for clients. All devices in vlan 30 are statically assigned IP addresses and not routable to the 10 and 20 vlan networks.  In all switches there are a variety of 802.1q trunked and access ports.

The idea of the lab is that vlan 30 can’t talk to vlan 10 or 20. However as a trunked port is presented to the Kali vm, it will be able to communicate to all vlans.

This is how it looks:

VLAN tagging in Kali Linux 2.0 - switch configuration

Lets look at how we would configure Kali to test all hosts in the different vlans, first via CLI and then via GUI in Network Manager:

As you can see with the current trunk connection we can’t access any of the networks, however a quick Wireshark does reveal we can see traffic and the different vlans…

First lets open up ‘/etc/network/interfaces’ in nano and add our interfaces. The idea is very similar to a cisco router we are essentially sub interfacing our network connection in the interfaces file:

Save our file and then simply bring up the sub-interfaces with ‘ifconfig XXX up’ where XXX is our subinterface:

We can now access all of our vlans in question.

Further to this, if we set off a ping to each network and Wireshark the trunk connection we can see our tagged packets. Hooray.

The Gui is even easier, lets configure it via the Network Manager. We will do this via opening up our network connections/Network Manager, simple click on the ‘+’ sign, select ‘VLAN’ fill in the details on the vlan tab as well as the ‘IPv4Settings’ tab:

And there you have it.

I hope this helps someone!


Searching for Exploits with

The needs no introduction. Most penetration testers will be well versed in the use of Exploit-db and its uses. However for new-comers, this is an excellent and ‘the go to’ resource when looking for exploits and exploit code for use in test labs on vulnerable systems.  It goes without saying though when looking through code that is published on the internet the following precautions should be taken;

  • Understand what the code is doing.
  • Modify the code if needed to suit your situation, especially any shellcode snippets.
  • Understand what lanuguage the code is written in.
  • Don’t run code from the internet without knowing what the code is going to do. You don’t want to create a reverse shell back to a C&C server do you.
  • Always test code in a lab, isolated from the internet and production systems.
  • Understand that some code such as C++ and C for example will most likely need compiling and need dependancies.


There are several ways to search the Exploit-db such as:

  1. Via the exploit-db site: however when searching for exploits you will have to use their captcher form in order to proceed with a search.
  2. Via Google search engine using the syntax: ‘ Windows Privilege Escalation’

    Google search of the Exploit-DB
    Google search of the Exploit-DB
  3. Using searchsploit built into Kali Linux like below, this has the added benefit that the databse is offline:

searchsploit in Kali
searchsploit in Kali

The offline copy can be updated with:

Hope you find this useful.


Python to generate all hex characters.

I came across a requirement whilst writing some exploit code to generate all hex characters available. The reason for this was to find all bad characters in a piece of shell code, as to not mangle the code when it is loaded into memory on the stack.

The following python will do the trick:

If you have a better way to be produce it let me know.



Creating username lists.

Just a quick post regarding creating username lists.creating username lists

Often during an engagement if you have discovered a service that is brute-force able such as smb then it would be advantageous to create a semi-valid username list. We can do this fairly easily with the harvester. Once we have this list we probably want to manipulate the forname and surname to create a valid username to suit our target. I came across this python script which quickly gives us the output we need. Full props to Harold Rodriguez superkojiman for his code: I have found that just removing the various outputs that you don’t want works best if you know the target username combination, and if you don’t run with all options. I’ve found the password/username spraying technique with a single password works best and is the smart option to avoid account lockouts.




Are LLMNR and NBT-NS really helping you?

In this post I’m going to be talking about LLMNR and NBT-NS. That’s Link Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS). They are backup name resolution processes that take place by default in windows networking to help your PC resolve names it requests. However are they really helping you or actually causing you more harm! I’l talk about why its bad, and why we should look to disable it.

Ok so what is LLMNR and NBT-NS, whats it all about?

Link Local Multicast Name Resolution (LLMNR) and Netbios Name Service (NBT-NS) are processes that take place by default in windows networking to help your PC resolve names it requests. When you PC needs to resolve the name or a server for example to an IP address it firstly uses the DNS server it has been assigned. If the DNS Server doesn’t have the record you requested, your PC will use LLMNR and then NBT-NS. With LLMNR your PC will broadcast across the local subnet and ask other machines if they have a record for the name you are trying to resolve. If no-one answers, your PC will then try NBT-NS in the same manner.

Lets see it in action, in the below wireshark we can see (Windows 7 domain joined machine) querying ( Windows Active Directory DNS Server) for the record of DC2. DC2 doesn’t exist, and as we can see the DNS server responds ‘No such name..’. The PC then proceeds to use LLMNR and broadcasts across the subnet. No response is given. The PC then tries NBT-NS and again broadcasts across the subnet, no response is given. No response is given as no-one on the subnet has that record, I just made it up to demonstrate LLMNR and NBT-NS.


Ok so why is this bad, surely its a good thing right..?

Well yes and no, more no these days. Ordinary and back some 10 years ago LLMNR and NBT-NS were used in helping resolve names. If the DNS Server was unavailable local hosts on the same subnet would help resolve names. However lets face it if your PC can’t use DNS its pretty much not going to be doing alot in terms of network connectivity and services. LLMNR and NBT-NS are just not needed anymore (usually). Attackers can take advantage of the LLMNR and NBT-NS broadcasts by replying to them with poisoned responses. The poisoned response can essentially trick the PC into thinking that it knows where the resource is. The PC then attampts to setup an SMB challenge response, in doing so sends its credentials along to the attackers machine. An attacker is able to capture the username and LM, NTLMv1 or NTLMv2 hash of the user making the request. This can then be subject to an offline brute force attack using several different programs such as John the Ripper or OCLhashcat. Or be reused in a PassTheHash or SMB relay attack.

Lets see it in action from wireshark.


We can see our usual DNS request, then an LLMNR broadcast goes out, as the DNS server has no record. Our attacker on (a kali linux machine using Responder) sends a response back to our PC ‘Standard query response,  DC3 is at’ this is actually the attackers machine fooling the PC. NBT-NS request hasn’t gone out at this stage as a response is received to the LLMNR. The PC is fooled into thinking the resource is at and starts to negotiate an SMB session, passing along its credentials to the attackers machine.

What can we do to fix it?

LLMNR and NBT-NS are old methods for name resolution. You may have legacy applications in your environment that may potentially still use LLMNR and NBT-NS for broadcast name resolution. Due to this thorough testing should be carried out first. If this is the case get onto the vendor for some answers as to why! Otherwise we can disable both via GPO and DHCP options. For LLMNR there is native GPO setting. For NBT-NS there is no native setting however it can be set in the registry. The registry key references an interface name which has its own unique GUID so can’t be changed in GPO via a registry key change (as the key will be different every time), however we can use powershell and do a ‘catch all’ on that key and thus script and then run via GPO. I’ll demonstrate below.

You can disable LLMNR via Group Policy in your domain or locally, go to:

Computer Policy -> Computer Configuration -> Administrative Templates -> Network -> DNS Client

In the DNS Client settings select “Turn Off Multicast Name Resolution” and set it to ‘Enable’ like below:

Disabling LLMNR

Disabling NBT-NS can be done in the windows networking as shown below:

On the ‘Advanced TCP/IP Settings’ screen select ‘Disable’ radio button for ‘NetBIOS over TCP/IP’.

Disabling NBT-NS

Changing the above will make the following change in the registry, value data 2 is for disable, 0 is the default setting:

NBT-NS disable via registry

Which in turn can be changed via powershell with the following line, this will change all interfaces (notice the tcpip* for the catch all):

This can then be scripted and set to run via GPO.

The process for disabling both are in the below video:

It obviously goes without saying the appropriate testing, change control and usual roll out procedures should apply especially with a change like this.


Unquoted Service Paths

Fixing Unquoted Service Paths in Windows.

This is just a short write up on unquoted service paths, what they are, why they are bad and how we can fix them. A vulnerabilty scanner will often find these on an ‘Authenticated’ type of scan. However we can search for them via WMI (Windows Managment Interface) query or by manually looking through the services one by one. So what is an unquoted service path? It is the path/file location of the service-exe for a given service that isn’t wrapped in quotes, like in the picture.

OK, so what? Why are these bad?

The problem with unquoted service paths is that as windows starts up or as the service is started Windows needs to locate the service-exe for that service. (I keep saying ‘service-exe’, well we’ll come on to that in a sec!). It looks for the service-exe in the path specified in the ‘Path to executable:’ field of the service. If the path is quoted and contains white space in the path windows knows to go directly to the location. If the path is unquoted and contains white space, Windows will essentially query the different locations in the path until the service-exe is found.

Where the service path contains white space and is unquoted, an attacker can use this to escalate privileges from a standard user account. For example if the service is running as SYSTEM, an attacker can create a service-exe to say create an account and drop it in the local administrators group. The attacker would also need to have ntfs permissions as the standard user in the location in the path so ‘C:\’ might not be viable however further down the path might be. The attacker then restarts the service and the new service-exe will be executed by the service running as SYSTEM.

The service-exe I keep refereing to is special type of executable file that is used by services, its not any old exe you can’t just drop cmd.exe in the path unfortunatly…

If I can’t do an Authenticated Vulnerability Scan how can I find them..?

We can use two methods, we can either use WMI query or manually open up each service and check each one, then check the ntfs permissions of each location. We can use the follwoing WMI command from Common Exploits; this will filter out the automatic service and also look for unquoted service paths:

Running the above wmi query will display something like the the following if present:

WMI Query of Unquoted Service Path

As we can see large mainstream manufactures still implment unquoted service paths!

I’ve found one, how do I fix it?

This is relatively straight forward however this should be tested before being rolled out into production (goes without saying). We need to add the quotes to our service path so windows know where to go for the service-exe directly immediatly, rather than searching each directory. We can do this through the registry.

Fire up the registry and navigate to the service as below:

Registry Unquoted Service Path imagepath

Open up the ImagePath string and simple add the quotes as below:


Restart the service and ensure the service starts properly. We can also open up the service and also re run the WMI query  to ensure our affected service now has quotes. This will ensure any attackers should they manage to compromise the machine as a standard user, stop them being able to escalte privileges in this manner!Unquoted Service Path Corrected

Hopefully this post will help you resolve the uquoted service path issue.