Windows Auditing – Turn it on and configure it.

Auditing is an important part of detecting system intrusions or malicious activity on your systems and network. The Windows Event Viewer does not log event entries in the security log unless you enable auditing on the system. This can be done easily through group policy or in the local security policy.

Solution

You can enable auditing on each Windows operating system on your network easily through Group Policy or locally. After you enable auditing, you can choose which events to monitor. Monitoring events such as successful or failed logon attempts. In addition, certain files and directories can be audited on NTFS file systems for changes.

We can achieve this locally by:

Navigate to the Local Security Policy editor. You can find this through either control panel or through: Start, run, type secpol.msc.

In Local Security Settings, double-click Local Policies, double-click Audit Policy, and then click the events that you want to audit.

Windows Auditing Local Security Policy

A better way to manage this is through Group Policy:

Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/AuditPolicy:

Windows Auditing GPO

Windows Auditing

Then apply it to your computers and servers.

Microsoft recommends the following:

Audit account logon events (Success, Failure)
Audit account management (Success, Failure)
Audit directory service access (Failure)
Audit logon events (Success, Failure)
Audit object access (Failure)
Audit policy change (Success, Failure)
Audit system events (Success, Failure)

The Center for Internet Security CIS benchmarks have recommendations per operating system. For example the CIS benchmarks for Windows Server 2012 R2 located here recommends the following.

26th April 201728th April 2017

The Shadow Brokers dump – Eternalblue, DoublePulsar – Hello SYSTEM!

Well The Shadow Brokers dump certainly tied up a proportion of time of the Easter weekend for myself and I suspect many infosec bods. It turns out the exploit framework known as fuzzbunch which was released as part of the dump is tied to the ‘Equation Group’ threat actor, the NSA’s Tailored Access Operations (TAO) according to Wikipedia. From my testing, this is the real deal and pretty effective at allow one to gain SYSTEM level access over an an unpatched supported operating system. It should be noted that many of the exploits have been patched by Microsoft in this months patch Tuesday, most notable MS17-010. Interestingly there is no attribution from Microsoft in terms of who tipped MS off about the vulnerabilities, one would question whether this was the reason why MS skipped the previous months patch Tuesday.

Utilising the exploit module Eternalblue and doublepulsar from fuzzbunch coupled with Empire or Metasploit is a quick win for gaining SYSTEM level access on any unpatched systems. If this is not patched in my view this is the next MS08-067 it terms of exploit-ability. The MS08-067 vulnerability was a classic RCE (remote code execution) and easy exploit for 9 times out 10 gaining SYSTEM level access in minutes on a pentest. In my view from my testing that I have completed in the lab with Windows 7 Professional 64bit this new vulnerability in SMB v1.0 is no different, requiring only a few extra steps. Ultimately allowing system level access in a reverse shell… yes those words should make your shudder at the thought. Ensure your systems are patched.

What is also interesting is that these tools are from 2011-2013, as they require early python versions. One can’t help but think there are a whole raft of new tools being used in the wild potentially by the other nation state threat actor groups. This point simply emphasises the need for secure configuration in addition to mandatory patching. If indeed tools like this are out in the wild we need to ensure secure configuration in the enterprise, ie segmentation, tightening host based firewalls (yes removing access to 445 on your clients), effective monitoring, to name just a few.

How can we detect Double Pulsar?

There are a couple of ways we can detect if double pulsar has been used. Using a vulnerability scanner such as Nessus we can firstly detect whether the Critical patch MS17-010 is missing:

Nessus will also detect whether double pulsar has been used on a machine by sending an SMBv1 Trans2 request .

In addition to this we can also use nmap’s scripting engine and invoke the smb-double-pulsar-backdoor to check if the target machine is running the Double Pulsar SMB backdoor:

smb-double-pulsar-backdoor

There are also some other specific detection scripts available on github by Luke Jennings available here and a auxiliary scanning module in Metasploit for detecting MS17-010 auxiliary/scanner/smb/smb_ms17_010.

How can we mitigate this threat?

Patch Patch and Patch some more, can’t emphasis this enough.
Stop using SMB1 as describing and advised by Microsoft in this blog post.
If you have SMB port 445 exposed on any systems review why and ensure only systems that need to access this port have access. Do your windows 7 clients really need this port?
Ensure your Firewalls are switched on and appropriate firewall configuration is in place. ie don’t just switch it on and allow everything through in any case.
Migrate your out of support systems XP and 2003 to new supported versions of MS Operating Systems.

Additional info from Microsoft on the Shadow Brokers was released here.

17th April 201728th April 2017

Windows Event Forwarding – Free Tools!

Windows Event Forwarding is a powerful tool and is also free unlike most SIEM options. Being able to log certain events back to a logging server is important, getting the right events logged is also equally important, and not being swamped with the wrong events. You really do need to know if someone is messing with your Domain Admins group or an LSSAS proccess on a member server.

In this post we will walk through setting up WEF (Windows Event Forwarding) in a lab environment to demonstrate how we can have better visibility over important security events in the domain. All without having expensive SIEM products, ie using what we already have.

For a bit of background, WEF has been part of Microsoft Operating systems for a while, being supported in Windows 7 right up to 2012 R2. Events can be either source initiated, ie sent from a client, DC or member server to a collector. Alternatively be collected by the event collector server itself. The idea here being that when an important event gets written to the Windows event log (Client or Member Server) it also gets forwarded to a certal logging server and thus the IT admins or security team get alerted to the event in some manner such as email. I posted a while back about doing this for Cisco kit with a Ubuntu 14.04 server utilising rsyslog for event collection posted here.

So our lab will utilise GNS3 as it gives us a good visual representation as to what we are working with:

As you can see, a pretty simple lab setup a Domain Controller (DC1) a couple of member servers (NPS and WEF-Collector) and client machines (W71, W72 and W73). We won’t worry too much about ESW1 or R1 at the moment these were just left over from an 802.1x lab I had been working on, the topology is just a flat 10.0.x.x network. The events will be written to our WEF-Collector Windows Server 2012 R2 machine.

First we will setup our Event collector server WEF-Collector. We will want to ensure WinRM the Windows Remote Managment service is started and Event forwarding is setup. Open an administrative prompt and type ‘winrm qc’ (you may find it is already configured as below):

Now to enable event forwarding on WEF-Collector our event collector. Go to the event viewer, select ‘subscriptions’ you will get a pop up – select ‘yes’ as we do want to enable event forwarding to start automatically if the server is restarted.

Now lets look how we can forward events to the collector ‘WEF-Collector’.

First we need to give the local Network Service principal rights to read the security log, we run the following ‘wevtutil gl security’ on machine in the lab to grab the channel access string (this will be used in our GPO):

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

Thanks to Jessica Payne with this article for discribing this section.

We will then append the string with (A;;0x1;;;NS) so it reads:

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)

This line is essentially where the permissions on the log are stored.

Now we will create a GPO so we can apply the settings to our clients and servers that we want to push events from, this will tell the clients and severs where to check for subscriptions and where to send events to ie ‘WEF-Collector’. We will initially want ot set two policies:

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Forwarding>Configure target subscription manager:

Note: Instructions are in the text of the GPO iteslf however in summary we want the FQDN, URL path, port and refresh time. Clearly checking every 10 seconds is overkill however for the lab its ideal.

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Log Service>Security> Configure log access:

This is where our channel access string comes into play.

Our GPO should look like this:

Now link the GPO to our AD structure to enable it.

Now our clients and servers are configured, lets configure some example subscriptions:

Logging Domain Admin changes sounds like a good idea, this is event ID 4728 and 4729. Start in the Event View, under Subscriptions select create subscription and fill in details like so:

Next select ‘Source computer initiated’, and in this case we are going to add DC1. Next we are going to go into the Select Events option and configure like so:

At the moment we can see that DC1 hasn’t yet checked in as the ‘Source Computers’ column is still ‘0’.

Once DC1 has checked in to see if there are any subscriptiosn for it we can see that the ‘Source Computers’ column is now 1, we can check the status by clicking on ‘Runtime status’. Here we can see DC1 is ready and waiting to send events:

If we now generate some events on our DC by removing and adding the user ‘Bob’ to the ‘Domain Admins’ group we can see the following two events have been logged in the ‘Forward Events’ section under the ‘Windows Logs’:

Clearly this is only based on two event ID’s however hopefully demonstrates what can be done takeing this example and expanding it, creating multiple subscriptions based on certain filters and IDs.

I hope this helps demonstrate WEF and how we can get much better visualisation into whats happening on the network for security events.

12th April 201728th April 2017

Linux Host Enumeration (Authenticated Post-Exploitation)

On a pentest once you have compromised a Linux host there stands a good chance you will want to go through further ‘Linux Host Enumeration’ from an authenticated position. If you have gained an unprivileged user shell such as a web user you are most likely also going to want to escalate your privileges to root or a higher privileged account and gather as much info as possible. The first stages of this are situational awareness and information gathering based on what you have right in front of you, ie starting with host enumeration. Now whether you have grown up with a Windows or a Linux background, you will probably be more au fait with one or the other. I tend to find as with myself people tend to fall into one camp or the other, probably simple due to the exposure and experience you have had with one or the other in the past. And the need to practice with the other, not so au fait side, is essential. For me I was more exposed to windows boxes.

This post will hopefully guide you through some of what I have learned with host enumeration for Linux operating systems, in this instance Debian Ubuntu. Commands will vary from distro to distro, however, this will give you a taste. Of course please feel free to comment on this particular post with what I have missed and I will be sure to update the post.

Starting on a Ubuntu 14.04 machine as root we would be looking to run the following, (some may seem obvious) however; this isn’t meant to be an exhaustive list more of a top commands:

System Information:

hostname
uname -a
cat /etc/*-release
cat /proc/version
route
arp
ifconfig
netstat -antp
netstat -anup
iptables -L
mount
dpkg -l
apache2 -v
mysql –version
cat /etc/resolv.conf
cat /etc/network/interfaces

User Information:

id
who
last
cat /etc/passwd (you will need a privilege account for this one!)
cat /etc/sudoers
cat history

Sensitive Files:

cat /etc/passwd
cat /etc/group
cat /etc/shadow

Potential SSH information:

cat ~/.ssh/authorized_keys
cat ~/.ssh/identity.pub
cat ~/.ssh/identity
cat ~/.ssh/id_rsa.pub
cat ~/.ssh/id_rsa
cat ~/.ssh/id_dsa.pub
cat ~/.ssh/id_dsa
cat /etc/ssh/ssh_config
cat /etc/ssh/sshd_config
cat /etc/ssh/ssh_host_dsa_key.pub
cat /etc/ssh/ssh_host_dsa_key
cat /etc/ssh/ssh_host_rsa_key.pub
cat /etc/ssh/ssh_host_rsa_key
cat /etc/ssh/ssh_host_key.pub
cat /etc/ssh/ssh_host_key

18th March 201717th March 2018

Stopping mimikatz from dumping clear text credentials.

This post aims to demystify what can be done to restrict mimikatz from running successfully in Windows. Specifically how we can mitigate clear text credentials being dumped out of memory. My aim is to demonstrate what can be done to the operating system configuration to help reduce this from happening. In a follow up post perhaps we will look into how we might be able to identify if this has or is happening to a machine on the network.

Once a user logs on to a windows system the credentials are stored in the Local Security Authority Subsystem Service (LSASS). Once creds are cached, from here, with various tools, not just mimikatz, credentials in the form of clear text and hashed passwords can be extracted.

Mimikatz for a pen tester is a really great tool, like wise also unfortunately for hackers. Created by Benjamin Delphy ‘gentilkiwi’ allows one to dump clear text credentials out of memory. It can do all sorts of other pretty cool things like perform pass-the-hash, pass-the-ticket or build Golden tickets, among others. Some of which I may walk through in the future.

Mimikatz can be executed from different sources. Either directly from an executable and also from powershell. The later being the more desirable as no files are ever touching the hard disk drive. A typical screen shot of successful dumping would look like this, this is what we are trying to avoid:

Here you can see the local account ‘Adam’ and the clear text password being displayed. This is clearly bad news for organizations, and an IT teams worst nightmare. An adversary would have to initially compromise a workstation or server and gain admin or SYSTEM level privileges. This might be through a classic remote code execution vulnerability like MS08-069. Or through some other weakness in the software, or mis-configuration in the operating system. An attacker from here on would move laterally from system to system dumping creds. Ultimately with the aim of snagging a Domain Admin, or capturing that key piece of business data.

This post isn’t necessarily concerned with showing you how to use mimikatz, rather it’s, to better inform IT teams how they can prevent clear text credentials being dumped. Any tester worth their weight will already know how to use it.

I’m going to test by running mimikatz natively on a couple of Windows operating systems in my test environment, make changes to the system then re-run.

I’ll run through executing Mimikatz and the preventative measures we can use to stop the software interacting with LSASS and dumping creds. Lets start with Windows Server 2012 R2.

Windows Server 2012 R2

When we run Mimikatz on a fully up to date system we get the following results:

Restricting Mimikatz

Note where the ‘Password’ field is for wdigest and kerberos , this would normally reveal the clear text password however in this case a ‘(null)’ value is displayed. This is default behavior in Windows Server 2012 R2 and Windows 8.1 and above, sadly for older operating systems such as Windows 7 the credentials are in displayed here in clear text. The NTLM hashes are still present here which still isn’t great and so can potentially be used in ‘pass the hash’ type attacks (PTH on the rid 500 account) or cracked offline using large password lists. Lets see what we can do to harden our systems further.

With Windows Server 2012 R2 and 8.1 there is a new feature called LSA (Local Security Authority) Protection according to the following Microsoft page we are able to run LSASS as a protected process. This essentially prevents mimikatz from working correctly out of the box. Although with some tweaking you can get mimikatz to run however a driver would need to added into the mix for it to work properly. The following registry change can be made at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa adding a new DWORD entry of “RunAsPPL” with a value of 1. This does require a reboot however. Lets see this in action on the same Windows Server 2012 R2 Server. First the registry key:

Restricting Mimikatz WDigest

Lets reboot, and now lets see what happens when Mimikatz is executed:

Restricting mimikatz WDigest

Thats more like it! Now we are getting somewhere. This is only going to slow attackers down. It is however also going to generate noise on the network when the attacker reboots the server.

Windows 7 Professional

A patch was released by Microsoft which allowed you to control the clear text credentials from the wdigest for earlier systems. This same functionality can be utilized by tweaking the registry for earlier versions of Windows. This is available for Windows 7,8,2008 and is kb2871997. Once this patch is installed it allows you control how WDigest credentials are stored in memory. According to the following Microsoft Security Advisor; to prevent WDigest credentials from being stored in memory. A reg key can be set via Group policy and thus applied to your estate. The registry key is new DWord with the name UseLogonCredential under the following subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.

If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.

Lets see how this works in Windows 7, first we will run Mimikatz to verify default behavior then we will add the WDigest registry key, reboot, test, then add the RunAsPPL registry key, reboot one last time and test again, lets do this!:

As with the standard behavior below we get clear text creds and hashes:

Restricting Mimikatz WDigest

Now lets add the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\ UseLogonCredential and set it 0:

Restricting Mimikatz WDigest

Lets reboot, and retry Mimikatz.

As we can see the password fields no longer contain our clear text password, and have the (null) value instead. This is a significantly better position to be in, this still does however, reveal the NTLM hash which is still not ideal. Unfortunately the RunAsPPL registry key, cannot be utilized in Windows 7.

Windows Server 2008 R2

Lets try the same with Windows Server 2008 R2. When we run mimikatz natively this is the result:

As we can see the local administrators account password for the wdigest field is in displayed in clear text. Now lets see if we can apply the same HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest\ UseLogonCredential registry key and at least mitigate the clear text password. First the registry key then a reboot.

After a reboot we rerun mimikatz and as we can see from the below screenshot we have successfully mitigated from the at least the clear text password being displayed, although the hash is still available:

However… this wouldn’t stop an attacker from changing the reg key back logging off and waiting for credentials to be cached.

Conclusion:

So far we have tested using mimikatz natively from the windows server 2012 R2 and successfully stopped mimikatz from executing the same should apply here for Windows 8.1 and above, however you should carry out your own due diligence and try this out to satisfy yourself. Windows 7 and Windows Server 2008 are slightly different and we can only go so far in stopping or slowing down this type of attack, to not displaying the clear text password only the hash.

Unfortunately with different versions of Windows there are different fixes and varying degrees of success in reducing the impact of mimikatz being run on a system.

As you will agree though this is significantly better than allowing the default configuration to remain. I hope this helps slow down your adversaries!

12th February 201730th April 2017

Searching for password files in PowerShell on a Penetration test!

Searching for password files in PowerShell

Searching for password files in PowerShell, can be particularly useful especially for post exploitation recon phase of an engagement. PowerShell is great tool for a penetration tester. Its post exploitation capabilities has grown exceptionally over the last few years. During the course of a penetration test once you have compromised a windows host there is a good chance that you will want to enumerate the host system further and gather as much information as possible. If you have access to a low privilege user you are likely going to want to escalation your privileges to higher account. This being known as post-exploitation. This will almost always likely include searching the local system for passwords. We will want to search for xlsx, docx are classics. Sure we can use the windows built-in gui however we can also use PowerShell. 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. Ace!

Get-ChildItem "C:\Users\" -recurse -filter *passwords*.txt

Simple, quick and very effective, this needs to be in your cheetsheet!

10th February 201719th June 2017

Conducting a PowerShell Port Scan – Post Exploitation

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:

$Server = Read-Host -Prompt 'Input your target IP/host' ; 1..65536 | % {$test= new-object system.Net.Sockets.TcpClient; $wait = $test.beginConnect("$Server",$_,$null,$null); ($wait.asyncwaithandle.waitone(250,$false)); if ($test.Connected){echo "$_ open"}else{echo "$_ closed"}} | select-string " "

$Server = Read-Host -Prompt 'Input your target IP/host' ; 80, 445, 3389 | % {$test= new-object system.Net.Sockets.TcpClient; $wait = $test.beginConnect("$Server",$_,$null,$null); ($wait.asyncwaithandle.waitone(250,$false)); if ($test.Connected){echo "$_ open"}else{echo "$_ closed"}} | select-string " "

And in action this looks like the below:

8th February 201730th April 2017

Conducting a PowerShell Ping Sweep

In this post we will look to see how we can conduct a PowerShell Ping Sweep. So you are on a pentest engagment and have just owned a box and can see an alternative subnet or have just pivoted into a new subnet. You know want to know what else is in that new subnet but can’t access it from your attack machine. You will want to see what is alive and so a quick ping sweep of the subnet is in order 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:

1..255 | % {echo "10.0.2.$_"; ping -n 1 -w 100 10.0.2.$_ | Select-String ttl }

This should look like this in action:

5th February 201730th April 2017

Pivoting with netsh in Windows – post exploitation goodness!

Move across a network by 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.

netsh interface portproxy add v4tov4 listenport=<LPORT> listenaddress=0.0.0.0 connectport=<RPORT> connectaddress=<RHOST>

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:

netsh interface portproxy show all

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

netsh interface portproxy reset

This all comes together like the below: (you can see here i have just used random ports just to give you an example how it looks).

Pivoting with netsh in Windows

Enjoy!

1st February 201731st March 2018

VLAN tagging in Kali Linux 2.0

Connecting to Trunked Ports!

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:

An alternative configuration for the interfaces file which I have used as well is the following, both work just as well:

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

‘ifconfig vlan10 up’ or ‘ifconfig eth0.10 up’ as below:

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!