Month: August 2018

Remote NTLM relaying through meterpreter on Windows port 445

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”

Creating a ram disk through meterpreter

The magical ‘in memory execution‘ option of meterpreter is of course one of the better options that we as attackers love to use. However if you want to store ‘random files’ in memory or need to execute more complex applications which contain dependencies on other files, there is no ‘in memory’ option for that as far as i know. To be more specific, on Linux you can do it with build in commands, on Windows you need to install third party software (list of ram drive software). I decided to dig into it and see if I could achieve this through a meterpreter session. The reasons for wanting a ram disk are multiple, if you are still wondering:

  • store stolen data in memory only, until you can move it
  • execute applications which require multiple files
  • running multiple legitimate files from memory

You might be asking, why not use it to bypass AV? This is of course possible, but you would need to modify the driver for this to work and ask Microsoft to sign it. To bypass AV there are enough methods available in my opinion, I sometimes just want to be able to store multiple files in memory.

Where to start? I decided to start with the ImDisk utility for two reason:

  • It is open source
  • It has a signed driver

The first reason allows me to better understand the under the hood stuff, the second reason allows me to use it on Windows versions that require a signed driver. First thing I tried is to use the bundled tools, but it seems that the command line interface has a dependency on the control panel dll file. I tried a quick recompile, but then I thought, why not code my own version? The original version includes, amongst other things, the ability to load and save the ram disk as an image file and for the moment I won’t be needing that functionality. So i decided to code my own reduced functionality version of the original client. It would have been easier to just use the original client, but this was more fun and thought me a thing or two about driver communication.

The original source code was very very clear, which made it a breeze to hack together some code to talk to the driver. I still need to add way more error handling, but for now it does the job and you can use it through meterpreter. Be aware of the fact that it still leaves traces on the regular hard disk, like explained in this blog. A short overview of the traces left behind:

  • The dropped driver
  • The registry modifications to load the driver
    • The driver loading does not use a service, thus there is no evidence of a service creation
  • The mounted ram disk
  • Traces of files executed or placed on the ram disk

For me the benefits of having an easy way to execute multiple files from memory outweigh the above mentioned forensic artefacts. In addition it becomes more difficult to retrieve the original files, unless the incident response team creates a memory image or has access to a pre-installed host agent which retrieves the files from the ram disk. Let’s get practical, here is how to use it through a meterpreter session (I won’t go into details on how to obtain the meterpreter session):

Continue reading “Creating a ram disk through meterpreter”