The hijacking of port 445 to perform relay attacks or hash capturing attacks has been a recurring topic for a while now. When you infect a target with meterpreter, how do you listen on port 445? A few weeks ago this topic resurfaced again in part due to Dirk-jan (
@_dirkjan) that saw this question flying by in the #bloodhoundgang slack channel and asked me to look into it. This sounded like fun to figure out and he promised that if it worked, he’d document a working setup that would be able to perform SMB relay attacks through meterpreter. Turns out, this is an already solved problem with readily available tools out there, but not a lot of people are aware about the solution.
We will explain how you can leverage these tools to perform relay attacks on a target on which you have a meterpreter session. The added benefit of this approach is the fact that you don’t need python2exe or a whole python stack on the infected host, just a simple driver and a meterpreter infection will do the trick.
The first part of this blog will focus on the thought process of being able to hijack port 445 and the second part of this entry will focus on making it usable for relay attacks. If you want to skip the thought process and relay setup you can also skip directly to the already available solution:
The rest of this entry is divided into the following sections:
- Who is the owner of port 445?
- Hijacking and redirecting port 445
- The full SMB relay setup through meterpreter
Please note that we took the easy route while writing this blog post and just put all the files on the disk. If you want to avoid that we suggest that you use a
ram disk solution or expand the current meterpreter in-memory execution functionality to support something similar to this.
In addition there is a high probability that you either have to recompile the source of the solution statically to ensure you won’t be needing additional DDL files or you’ll have to bundle those DLL files. All this is however left as an exercise to the reader ;)
Continue reading “Remote NTLM relaying through meterpreter on Windows port 445”
So after my last article, in which I describe an alternative way to execute code on a remote machine if you have the local administrator’s password, I kept wondering what else could be done with the remote registry? The first thing I immediately thought of was dumping the windows hashes. The reason I thought of this was because it would have several advantages:
- You would not need to bypass anti virus
- You would not need to worry about uploading executable files
- You would not need to worry about spawning new processes on the remote machine
- You would only need one open port
Since I dislike reinventing the wheel (unless it’s for educational purposes) I started to first search around and see what current methods are available. As far as I can tell they all boil down to the following:
- Use psexec to dump hashes by
- Spawning a new process and running reg.exe
- Uploading your own executable and running it
- Use WMI to spawn a new process and run reg.exe
- Use Windows tools
- regedit.exe / reg.exe
- Third party (WinScanX)
If you are not interested in my first failed attempt, the learned things you can skip directly to the script on GitHub as usual. Keep reading if you want to know the details. In case you are wondering: Yes I used impacket, it rocks.
Continue reading “Remote hash dumping: no processes or tool upload needed”
For me the fun in hacking still remains in finding new ways to achieve the same goal. On one of those days with splendid sun and people having their beer, I thought it would be a good idea to start researching how to get a remote Windows shell without using any of the more well known methods and preferably from a Linux host. To set the proper context I’m talking about the situation where you have gathered local administrative credentials and want to start gathering shells all over the network. I started to research the current methods and see how they worked the way they did. Then I did a lot of searching around and also some basic process monitoring stuff. This eventually gave me what I wanted a new?? way to start remote processes without using any of the known methods BUT unfortunately it has one possible drawback: it is not instant like the other well known methods. Depending on your goal and time this can be as much a drawback as it can be an advantage. The actual method IS NOT really new it’s just used in a remote way. Let’s do a quick recap of the ‘well known’ methods I’m referring to, to make sure we are on the same level:
This is probably the most well known one and implemented in a dozen ways. The basics revolve around uploading an executable and creating a service that starts the executable. It’s efficient, reliable and thoroughly tested. It works from Windows and Linux hosts.
Windows Management Instrumentation (WMI)
This one is often used from visual basic script files or powershell scripts to exeute processes remotely. As far as I can tell it uses some undocumented dcerpc functions. It works very nice from Windows host, but I haven’t seen a Linux implementation yet. There is a libwmi library but I think it only does WMI queries, please correct me if I’m wrong.
Windows Remote Management / Shell (WinRM / WinRS)
This one is pretty neat since it uses the mechanisms provided by Windows to give you a direct shell without uploading anything or making use of temporary files. There is a nice write up about it on the rapid7 website.
Managed Object Format (MOF)
This one seems to have come into existing with Stuxnet and is pretty sexy. All you have to do is drop a correctly prepared file and Windows will execute it.
Looking at all these methods there are a two things that caught my attention:
- DCE/RPC is pretty powerful
- Eventually you want to upload your own executable (ex: meterpreter)
If you are impatient you can skip to the source of the POC on github, if you want to know more keep reading.
Continue reading “Alternative psexec: no wmi, services or mof needed”