From zerosum0x0:

Exploitation and Caveats:
1. You register with channel MS_T120 (and others such as RDPDR/RDPSND) nominally.
2. Full RDP handshake, I like to wait for RDPDR handshake too (code in the .py)
3. You free MS_T120 with the DisconnectProviderIndication message to MS_T120.
4. RDP has chunked messages, so we use this to groom.
   a. Chunked messaging ONLY works properly when sent to RDPSND/MS_T120.
   b. However, on 7+, MS_T120 will not work and you have to use RDPSND.
       i. RDPSND only works when HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\Winstations\RDP-Tcp\fDisableCam = 0
       ii. This registry key is not a default setting for server 2008 R2. SHITTY ISSUE
5. Use chunked grooming to fit new data in the freed channel, account for the allocation header size (like 0x38 I think?). At offset 0x100? is where the "call [rax]" gadget will get its pointer from.
   a. The NonPagedPool (NPP) starts at a fixed address on XP-7
       i. Hot-swap memory is another SHITTY ISSUE. With certain VMWare and Hyper-V setups, the OS allocates a buncha PTE stuff before the NPP start. This can be anywhere from 100 mb to gigabytes of offset before the NPP start.
   b. Set offset 0x100 to NPPStart+SizeOfGroomInMB
   c. Groom chunk the shellcode, at *(NPPStart+SizeOfGroomInMB) you need [NPPStart+SizeOfGroomInMB+8...payload]... because "call [rax]" is an indirect call
   d. We are limited to 0x400 payloads by channel chunk max size. My current shellcode is a twin shellcode with eggfinders. I spam the kernel payload and user payload, and if user payload is called first it will egghunt for the kernel payload.
6. After channel hole is filled and the NPP is spammed up with shellcode, trigger the free by closing the socket.
TODO:
* You can use the scanner methodology to detect x86/x64, but I'm still not sure how to detect OS, other than XP nominally will not use SSL and 7 will.
* The whole thing needs to be swapped to the Ruby version. Tom Sellers client is nicer and works for XP whereas this python client will not (when I wrote this module it was still in progress)
* Write the XP/2003 portions grooming MS_T120.
* Can we detect if RDPSND grooming is working or not?
* Any channels besides RDPSND/MS_T120 work for the grooming? (I've gone through about 10 books on NT RDP and reversed enough to doubt it)

https://github.com/0xeb-bp/bluekeep .. this repo has code for grooming MS_T120 on XP... should be same process as the RDPSND

When dealing with the RDP mixin it makes more sense to not expose
TCP-level things, instead it's better to talk RDP. This changeset makes
it so that consumers of the RDP mixin talk RDP only. They can access the
socket through the `rdp_socket` member if required, but the changes made
here mean they don't have to. Ultimately, this new member should be
`private` instead of `protected`, but I'm leaving it like this for now
in case it is required down the track.

I've also made the assumption that all RDP connects want TCP_NODELAY
set. This might be wrong, but I don't think it is.

From here, users can call `rdp_connect` and `rdp_disconnect` to manage
connectivity to the RDP endpoint. The `rdp_connect` function does not
register the TCP client socket as the global `sock` member on the TCP
module instance, this is to prevent the mixin from clashing with other
users of the TCP client in a given module.

This code is at the point where we SHOULD see a crash (given that the
payloads in use for kernel/user are both just As and Bs (deliberate at
this point).

Unforunately the exploit does not result in a crash. Things just keep
on going! I've looked at the difference in the traffic across the two
different exploits (py and rb) and what's clear is that the mixin is
doing a lot more work at the start.

Also, the mixin generates packets of smaller size in the way that it
encodes data (ie. it doesn't always use 2 bytes for a short value, it'll
use 1 instead if only 1 is required).

Pretty sure that the size issues aren't the problem, I think there's
something else in play. I'm at the point where diving into the RDP stuff
even more isn't inspiring so I'm hoping that opening this up to collab
will help us move forward.

For some reason the existing kernel payload doesn't work with the
exploit as it currently stands, which is very odd given that everything
else seems to be in order.

Hoping to get some help from the rest of the MSF folks as right now
I don't think I can trust the tools that I'm using.