GhostPack was recently released by Will Shroeder. This is a great package of C# offensive tools. C# is a relatively untapped part of the offensive toolkit with some unique opportunities and challenges. It is great because it gives you a great API that you can live off of, it is sometimes a challenge as different versions aren’t always consistently installed across different organizations. In this post we are going to talk about applying a concept that I developed to one of these tools to reduce detection surface as much as possible. The tool we are going to look at is SafetyKatz which wraps normal mimikatz in C# which in turn wraps some unmanaged code using a PELoader technique created by Casey Smith. Essentially what this post boils down to is shrinking the on-disk footprint of SafetyKatz from about ~700KB to about 5KB and loading the rest over http or https using a technique I call .Net over .net.
TLDR:If you aren’t interested in the details and you have always wanted to run python on top of .Net in 5 lines of powershell or less, skip to the bottom for code snippets. If you want to figure out how that is possible read on…
I have been digging into .Net recently, trying to stretch the bounds of the .Net Framework and have a very cool discovery to share. Anyone who is interested in the offensive side of security is always looking to limit the amount of attack surface that is available to various security controls, when trying to get shells on boxes. This article will hopefully teach you a bit about the .Net framework, as well as about how to pull and load .Net assemblies over the Internet into a C# application or even more interestingly… PowerShell. The resulting C# applications are around 6KB. The resulting PowerShell applications are just a handful of lines of code. Imagine having all the power, benefits and extensibility of managed .Net code without the footprint. As an example, we are going to run (Iron)Python on top of .Net, over the internet. Here is how.
Intro to Mimikatz
One of the most interesting tools in a penetration tester’s arsenal is mimikatz. Mimikatz is a tool that scrapes the memory of the process responsible for Windows authentication(LSASS) and reveals cleartext passwords and NTLM hashes that an attacker can use to pivot around a network. From that point they escalate privilege either by authenticating with the clear text credentials or passing the hash. Sounds deadly right? Most people have the reaction “Why hasn’t Microsoft come up with a solution to this?”.
If you Google the phrase “defending against mimikatz” the information you find is a bit lackluster. The best article I have found was this one. It has a lot of good suggestions like using the “Protected Users” group(SID: S-1-5-21-<domain>-525) available in recent versions of Active Directory and also limiting administrator usage, and taking advantage of not storing passwords in memory with a registry setting. You can limit the number of services running as system or remove debug privilege to help prevent an attacker from being able to run mimikatz. What this and other articles make you believe is that you need to have Windows 8 or 8.1 or 10 rolled out everywhere. What about the large number of Windows 7/2008 R2 machines out there? Well it turns out you can defend against mimikatz on these versions of Windows, here is how. Read Full Article
I love SSH, coupled with byobu(an updated GNU screen) it is amazingly powerful. But sometimes it is really useful to be able to view a GUI application on the remote server end. Some people think that they need to use VNC to do this. VNC is terrible, and there is a better way.
Things you will need:
- An X capable SSH client
- A server that has a graphical environment installed on it
- Ubuntu Desktop is an easy example
- Gnome/KDE/XFCE/X11 etc.
- SSH server installed on the server
- A GUI application that you want to run over SSH
In my example I’m going to be connecting from a Windows computer, using MobaXTerm, to a Ubuntu Desktop machine, and running WireShark(yes I know about tshark).
Make sure sshd is installed on the Ubuntu machine.
$ sudo apt-get install ssh
Back on the Windows machine, we SSH to the Ubuntu machine. Notice that we are specifying -X which allows us to run X applications over SSH
$ ssh -X firstname.lastname@example.org
Then we run our application
That is Wireshark running on the remote Linux machine. Notice the GTK/Ubuntu looking buttons, and the Windows colored Window frame.
Thanks for stopping by!
Most IT people are somewhat familiar with Wireshark. It is a traffic analyzer, that helps you learn how networking works, diagnose problems and much more.
One of the problems with the way Wireshark works is that it can’t easily analyze encrypted traffic, like TLS. It used to be if you had the private key(s) you could feed them into Wireshark and it would decrypt the traffic on the fly, but it only worked when using RSA for the key exchange mechanism. As people have started to embrace forward secrecy this broke, as having the private key is no longer enough derive the actual session key used to decrypt the data. The other problem with this is that a private key should not or can not leave the client, server, or HSM it is in. This lead me to coming up with very contrived ways of man-in-the-middling myself to decrypt the traffic(e.g. sslstrip or mitmproxy).
Session Key Logging to the Rescue!
Well my friends I’m here to tell you that there is an easier way! It turns out that Firefox and Chrome both support logging the symmetric session key used to encrypt TLS traffic to a file. You can then point Wireshark at said file and presto! decrypted TLS traffic. Read on to learn how to set this up. Read Full Article