Since these stagers can shrink based on the expected size of the next
stage, do our best to anticipate a small size. This makes the cached
payload size consistent for now, though if the x64 mettle stager grows
past 128 bytes I think we'll see the stager start oscillating in size
again. If you run into that and are reading this, sorry :(
See notes for x64.
This part does not appear to be working properly yet - stages
generated with this commit recv 102b on the first call to read(),
but subsequently things seem to go off the rails after the
intermediate stage is loaded.
Needs testing and fixup at present for x86 (no worse than before
in terms of success rate however).
The linux x64 reverse tcp stager is hardcoded to read 4K off the
socket. When a small intermediate stager is used, this can result
in reading part of the next stage as well, which means that the
intermediate stager will never recv the # of bytes it needs and
hang indefinitely.
Break out the mettle piece to use separate methods for assembly and
binary payload generation as well as actually putting the product
on the existing session socket.
Change the first part of the stage to check for the intermediate
stager generation method, and use the size of the produced stager
in the recvfrom call or fall back to the prior 4K read size.
Testing:
None yet
Ping @bcook-r7, @acammack-r7, @OJ, @ZeroSteiner
GPO files on SYSVOL do only include the GPO GUID, not the GPO name defined by the administrator. This modification makes this gpp module make an ADSI query to retrieve all of the domain's GPOs, and compare their GUID. If one GUID matches, then we know the GPO name and we can display it. On a pentest, a client is much more interested by knowing the GPO name rather than the obscure GUID. The ADSI query relies on meterpreter "extapi" extension.
James Lee