Sunday, March 27, 2016

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

Still continuing 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.

Similar to the log analysis, I wanted to see what I could learn about my activities from a memory analysis.

So the last thing I did before I shutdown the Windows 2008 box was to take a memory dump using DumpIt.









Once I had the memory image, the first thing I did was run the "imageinfo" module on it. Obviously I did not need this as I know what the image is, but force of habit and wanting to get information like the KDBG and KPCR, etc resulted in this command being run.
Above, we gather some information about the image.


Next let's look at the network connections using the "netscan" module to see what is established. However, looking for what is listening is just as important as it can tell you if there is a backdoor waiting for connections.

Below we see there are two established connections but the one that is of greatest interest to us is the one for "powershell.exe"
Let's take a look at the process list using the "pstree" module and focus on the "powershell.exe" process associated with PID "644".
I find this strange that this process has 0 threads and what looks like no handles as shown below. However, according to the Eric Pepke in this post, processes with 0 threads are zombie processes and will still have an entry in the process table. I'm ok with this explanation. Moving on!


Looking for more interesting stuff with the "pstree" module we see the following.

Above we see mimikatz has a PID of 3744. However, remember we migrated to process 2772 in this post. So the Parent of mimikatz is actually the conhost process we moved into once we gained access to the Windows server.

Additionally, as we look at the process tree we can also conclude that "esentutl" and "ntdsutil" are also children of "conhost" with PID 2772.

Let's poke around to see what we can learn from mimikatz
Using the "cmdline" module we see that mimikatz was started from "C:\x64\" folder

Let's run "cmdscan" to see what we can gather.


Looks like we got conformation that mimikatz was run from the command line.

Let's look a little deeper with the "consoles" module

From the above we learned a little bit more about the execution of mimikatz. 
Looks like this was mimikatz 2.1 x64 (oe.eo).
We also see here that mimikatz was attached and uses PID 3744. 


When I looked at the handles associated with PID 3744 (Mimikatz), I saw there was a handle of type process that was associated with "lsass.exe".

When I compared this to a few other processes, namely "svchost", "lsm", "ntfrs", "conhost", "vds" there was no reference for process lsass.exe. So I thought this was interesting.


Next up I ran the "malfind" module on the lsass process which PID is 448.


From the above it seems there is injected code in the lsass.exe process.

Next up I added the "--dump-dir=/tmp" to above and then submitted the file to VirusTotal


Finally, I wanted to confirm the permission mimikatz was running with and I did this using the "getsids" module as shown below.

Ok at this point I felt this was enough for now. Virustotal did not detect this as anything malicious. This could have been for a number of reasons, some of which could have been my fault. However, I know it's not an executable. More importantly I am still working on improving my reversing skills so I left this alone for now ;-)

Hope you enjoyed this series.

Reference:
https://www.quora.com/Can-a-process-have-0-threads-or-does-one-process-always-have-one-or-more-threads-of-execution
https://github.com/volatilityfoundation/volatility/wiki/Command-Reference
https://www.aldeid.com/wiki/Volatility

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 - Log Analysis

Still continuing 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.

So yeah I spent time learning about the tools and what they do. However, are there any signs I may be able to use that may help us detect these activities. The reference section have suggestions for detecting and mitigating some of these activities I performed, more so around the mimikatz side of things. However, along with those I wanted to know what I may be able to detect from my lab.


So here we go .... Blast off!!!!!


When I'm investigating, I typically start with a trigger. Something that I'm aware of that may be the cause of the issue. In this case since I created the issue, I will started with a time window and then remove what I didn't want.


First thing that I detected in the Splunk log was
the strange computer name shown below.















Next I noticed a service with a strange name starting.
















Not only was the name strange but it had what seems to be base64 encoded string and gzip compressed. So I wanted to peek a bit more into this.

I then copied the base64 encoded string and "echo" its value and "|" it into "base64 --decode" then sent this to a file named "services.gz" as shown below.


Next step was to verify the service.gz file was successfully created as shown below. Once it was I performed a "file" on it to verify it was gzip compressed. I wanted to peak at some details about the files so I ran a "gunzip --list" and finally "gunzip" the file. This then created an ASCII file as shown below.


Once this was all done, I now wanted to see what was in the ASCII file so I "cat" the file and found ...

..... it was more code. Time to move on for now as the objective of this post was not to analyze the code. However, by analyzing this code an analyst can get a better understanding of what the code is trying to do.


Something else that caught my attention was the starting and eventual running of the Volume Shadow Copy Service as shown below.


Do remember that in order for Metasploit to grab the database, it needed to start the service as it was not running. So this may be something to look for to see if Volume Shadow Copy service is being started on your Domain Controllers.

I then saw the "ntds.dit" location was changed. Another cause for concern?

The next image was also of concern to me because I know the conhost service is the one I migrated to. Therefore, I take it this service was responsible for initating the copy. Maybe in a future post I can look at the process or user who is responsible for starting this service. However, for now I know I migrated to the conhost process, so it's quite likely why I'm seeing this activity under this process.
Ok then, I'm not trying to make this post too long. However, the rest of the information which can be found in the reference section can help in detecting mimkatz and or its activities.

This post was just for me to see what else I may be able to see about my activities other than what was shown in the reference documents.



Reference:
http://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/
https://adsecurity.org/?p=1275



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 - Exporting Certificates

Still continuing 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.

When I performed this task within meterpreter, for whatever reason I was not successful. However, when I did on Windows I was ;-)

So here we go.
First up, I loaded mimikatz and verified that I was good to go.

Looks good!


Let's see what certificates are immediately available for the user.

So we have a certificate for administrator and its key is exportable too.

Let's export!

So Mimikatz claims it exported the public key as a .der file and the private key as a .pfx file. 

Let's verify this is so!

I Guess Mimikatz did not lie :-)

Let's add this to our personal store.



























The password for the private key is "mimikatz".

Once the password is accepted we can complete the installation as shown below.



























Let's now verify this is in our personal store.



Verify the thumbprint!






























So we have the certificate installed and we have its private key.

What next should we do?

Let's make "Administrator" a recovery agent for the local user EFS encrypted file as we see below "Administrator" has "File Recovery" as one of its intended purposes.

So I created a file named "EFS Testing" and encrypted it with EFS as shown below. We can see the "Recovery Certificate" belongs to "SECURITYNIK\Administrator". This certificate came from the logged in administrator of the domain. Additionally, by looking at the Certificate Thumbprint, we know that this is the certificate we imported above.


So that's it for me on this post. Now that you have both the public and private key you can decide on what level of badness or goodness you would like to perform. Let your imagination run wild!



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 - Pass The Ticket (Golden Ticket)

As we continue this journey of learning about Mimikatz, SkeletonKey, Dumping NTDS.dit and Kerberos with Metasploit the objective of this post is for me to learn a bit more about Passing The Ticket (Golden Ticket) using mimikatz.

With a golden ticket you can gain access to a domain for a user who does not even have access to that domain. So this was obviously interesting to me.


First up, let's load up mimikatz and ensure we are good to go.


Let's see the various hashes for the information from the "krbtgt" account that will allow us to create our golden ticket.


Looks like we have a few choices. Let's use the AES256 hash.

Good stuff looks like we were able to create a ticket for the user EvilUser.

Additionally, we have assigned this user to the Domain Admins, Domain User, Cert Publishers, Enterprise Admins and Schema Admins groups. Now that is a lot of privileges this EvilUser has.

Time to verify that the ticket was created successfully.


Good stuff! We are now on our way to passing the ticket.


But before we pass the ticket, let's see if any tickets exist.







Looks like we have none.

So then let's ensure there is one then.






Looks good! Let's see what mimikatz says about this ticket.



Well I guess a lot was said by mimikatz. Let's see what the native Windows tool klist.exe says.


It says much the same thing. Looks like progress was made creating the golden ticket.

I wanted to do some additional validation on this. However, I did not have a x64 machine to test. So this is it for now. I'm confident that this works based on the additional research I've seen other people have done.


Set you in the next post where we start to look at the logs.




Reference:
http://www.slideshare.net/gentilkiwi/abusing-microsoft-kerberos-sorry-you-guys-dont-get-it
http://www.emvlab.org/dumpasn1/upload/
https://support.microsoft.com/en-us/kb/243330
https://adsecurity.org/?p=1515
http://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/Using_Kerberos.html



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 - Skeleton Key

So skeleton key like mimikatz was something I learned about recently and was interested in. So this post is one is for me to understand how to use these features and hopefully log and or detect it.
According to Dell SecureWorks, skeleton key uses a method of bypassing AD authentication when single factor (password) authentication mechanism is used. Basically a malicious actor can assign a "master" password to the AD domain and thus login as any user.

So how do we test this?
We will leverage information we learned in the previous posts, specifically this one and this one.

Since most of the work was done in the previous posts, let's just go ahead and install the "skeleton key" using mimikatz.















From above we see skeleton key has been loaded. 

Let's now test this by trying to connect to a network share on the DC from a Windows 7. Below I use the password "Blogging1" with the username "tUser" and was a able to successfully map drive "F" to the "tmp" share on the server and perform a "dir" to view the files in the directory.






Similarly below, I connect to a network share on the DC from a Windows 7.  In this scenario however, I use the "master" password "mimikatz" with the username "tUser" and was a able to successfully map drive "F" to the "tmp" share on the server and perform a "dir" to view the files in the directory.

Both examples above clearly demonstrated that this worked as expected.


According to Dell, skeleton key does not have any type of persistence at this time, thus by rebooting the Domain Controller, the system will no longer be affected.

Similar to the other posts, we will try to analyze all of this activity when we look at the log analysis in this post.

Reference:

https://adsecurity.org/?p=1275
https://www.secureworks.com/research/skeleton-key-malware-analysis


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