Got an issue where certain functions aren't being resolved and hence are
null when being invoked. Need to debug the loading of the DLL to see why
this is the case.
Add support for loading RDI-related stuff using ordinals instead of
function names. Remove exports from the extensions/etc. This is another
step in the direction to make the DLLs less obvious.
Extensions no longer have their own name in the library metadata.
They're all "extension.dll". Metsrv is now "server.dll" and the two
non-extensions are "plugin.dll". I was going for something a little less
obvious.
This required changes to the RDI functionality.
Add support for loading RDI-related stuff using ordinals instead of
function names. Remove exports from the extensions/etc. This is another
step in the direction to make the DLLs less obvious.
Extensions no longer have their own name in the library metadata.
They're all "extension.dll". Metsrv is now "server.dll" and the two
non-extensions are "plugin.dll". I was going for something a little less
obvious.
This required changes to the RDI functionality.
Enumeration of commands was a bit of a hack, and still resultsed in
strings (like "stdapi") to appear in binaries, and also meant that
extensions needed to identify themselves.
This code changes the way this works. Extensions no longer have a name.
Instead they have an internal ID tha maps to the command sets they
support. To enumerate extension commands, MSF will ask for a range of
commands, and if any command IDs fit within that range, they'll be
returned.
This moves us towards a nicer way of handling things across all the
meterpreters.
We now use ints, and hopefully this means we don't have as much obvious
stuff in the binaries!
```
$ # Before:
$ strings metsrv.x86.dll | grep core_ | wc -l
46
$ # After:
$ strings metsrv.x86.dll | grep core_ | wc -l
0
```
Big win, and it's even bigger for the likes of stdapi.
Had to fix a bunch of other stuff along the way, including a subtle
issue with the Powershell Meterp bindings.
This commit includes a bunch of changes that are working towards being
able to build the Meterpreter source from CMake. Changes include:
* Updated `make.bat` which does the stuff that we need.
* Removed a bunch of stuff from the python extension source tree so that
CMake generator would not include them.
* Moved a few things around in the priv extension.
* Created `CMakeFileLists.txt` for all the projects.
There are a few hacks required in things like stdapi and kiwi to ignore
files that are on disk but shouldn't be included in the build.
Initial testing indicates that sessions run, extensions load, but some
things don't work as intended. It's a start! Still much to do.
I am sad. Like.. really sad. I'm sad for so many reasons. For nearly
7 years I've worked on this god forsaken source, and for many of those
7 years I have had the ext_server_mimikatz project configured to have
warning level 3, and warnings as errors. While making changes to the
build systems in the last week or so, I've even rebuilt this on updated
toolsets on multiple platforms.
Despite all this, one thing slipped through the cracks. I have NO idea
why this warning wasn't shown in th past. Also.. how did this ever
work!? Why is it that it's only rearing its ugly head now? I honestly
don't know. Based on the code that I've had to fix in this PR, there's
no reason why this should build without warnings on any machine. Yet, it
does. It builds clean on my Windows 10 desktop with VS2013/2017/2019.
Same on most of my other virtual machines. For some reason it only
failed on this one VM after I had to fight to reproduce it when Brent
hand an issue.
The issue here was that a `string` type was being constructed from an
iterator over a `wstring` type, and hence there was an implicit
character conversion from `wchar_t` to `char`. This SHOULD be a warning,
because clearly that's not a good thing. BUT HERE WE ARE.
Anyway, we're proxying via the `_bstr_t` type now to avoid having to do
horrible manual character conversions. Given that we're in C++ land
already there's no point in working any harder. Also, this extension is
probably going to go away soon anyway, so a temporary fix that does the
job is good enough.
RIP my morning. I won't be getting that back.
The video and audio capture things didn't do anything other than leave
artifacts on disk. So this commit removes the code that does that,
resulting in just one feature being available for this extension. Might
be worth ditching it entirely?
The 'common' library has been removed. The only project that actually
used it was metsrv, so the code that metsrv required from common is now
directly compiled in as part of that project.
The common folder now contains files that are importanta cross all of
the projects, with a primary focus on the new "API" style function. What
this means is that MetSrv has an API that it exposes through a function
pointer that is passed to the extension when it's initialised. This
pointer references a structure with all the API functions wired in. This
means that:
* Extensions don't need to know anything about metsrv at compile time.
* The delay loading code can be removed, which was one of the last
instances of "metsrv.dll" as a string.
* Metsrv.dll no longer exports any functions.
More to come.
This was a bit of a pain, but was well worth it. Had to add a couple of
hacks to make it all work, but this is a nicer solution than having to
depend on OpenSSL and its horrendous build experience.
Warnings as errors, builds clean. Had to do some horrible hacks:
1) Include custom implementation of a lib function just so we could
link against stuff built with older VS.
2) Include legacy symbols for old io for the same reason.
I found an edge case where stageless payloads did not work when they
were embedded in .NET applications. The reason for this is because the
configuration block is stored alongside the code in stageless payloads
and hence is loaded into memory as part of the section when it's mapped.
This section, in native world, remains RWX, and hence we don't have a
problem reading from and writing to it. We write to it for various
reasons, such as when the session guid changes.
In .NET land, this section is mapped as RX instead of RWX. This means
that when we try to write to it, the program segfaults due to an access
violation.
This code modifies the loading of the configuration so that instead of
maintaining a pointer to the original configuration, it instead creates
a copy of it on the heap. I preferred this fix over marking the memory
as RWX, which obviously stands out a bit more.
DWORD dwResult = ERROR_ACCESS_DENIED; -> DWORD dwResult; (in functions search_all_drivers, request_fs_search)
Comments in function request_fs_search were deleted
Windows Meterpreter that uses http/s-based transports wasn't correctly checking for cases where pivoted packets were handled. When pivoted packets are forwarded to the correct handler, the packet is set to NULL. For TCP transports, a check already existed to carry on when the packet was NULL, but this wasn't the case for HTTP/S.
This commit fixes this problem and so the pivot session no longer dies when Meterpreter is using an HTTP/S transport.
For funzies, the fix for this was implemented on a live stream to help other people learn some of Meterp's internals. That video can be found here: https://www.youtube.com/watch?v=de-UYWnafow
This commit adds two new scripts and modifies some of the powershell transport binding functionality.
Code has been added that generates valid Metasploit URIs for use with stageless listeners. This means that it's possible to add HTTP/S transports on the fly and have a URL generated that will work with the current architecture of the process.
Two new scripts will appear in each of the powershell sessions:
* Add-WebTransport - adds http/s transports to the session.
* Add-TcpTransport - adds TCP transports to the session.
These two scripts are just abstractions on top of the built-in Meterpreter transport binding functionality, but it makes it a lot easier to interact with the feature and makes it more.. er.. Powershelly.
The functions come with documnetation, so `Get-Help Add-WebTransport -Full` will show how it's used.
From here, people can do some more fun stuff, such as adding init scripts to their stageless payloads that add support for more transports.
I stuffed up when dealing with values that are being passed back and forth across components when in x86 processes. I was passing 64 bit ints around even in 32 bit mode, which resulted in some natstiness. This commit fixes that problem by forcing everything to be 64 bit regardless of arch, and casting to the appropriate pointer at the right time.
The previous commit hard coded the LM hash to the empty value. This commit changes this so that if the LM hash isn't present it'll manually specify the empty one, but use the existing one if it is present.
This commit changes the channel functionality within the powershell extension so that commands do execute behind the scenes and stream the results to the UI in the current channel.
This comes with the caveat that users are patient. I haven't yet made sure that running separate commands while long running ones are running will not cause problems. We'll have to see.
DCSync functionality is exposed, and from this it is possible to enumerate all users in the domain and dump each user's hash one by one. This code has a few extension functions built into the runner, and also has some baked-in powershell functions that are available in every powershell runner session in the host.
I've also added a powershell version of the build command that lets us generate the source to the powershell assembly wiring from PSH as well as Python.
This was left over code from me trying to do some fixes to getprivs
which didn't make sense in the middle of the packet pivot work. This was
left over by me as a result of my half-baked revert. This caused issues
with both the `getprivs` and `getsystem` command. I'm pretty sure that
as a result of breaking the latter, I will never live down the "make
getsystem great again" meme.
