RDP module failing to log on using successful credentials to Windows Server with RDS role

[jeffmcjunkin]

Describe the bug
Using valid credentials and a development copy of the latest NetExec fails to log in against a Server 2016 RDP server.

To Reproduce
Steps to reproduce the behavior i.e.:
Command: poetry -C C:\tools\NetExec run NetExec -- rdp -u "validuser" -p "validpassword" -d thedomainname.com rdp01.thedomainname.com
Resulted in:

PS C:\WINDOWS\system32> poetry -C C:\tools\NetExec run NetExec -- rdp -u "validuser" -p "validpassword" -d thedomainname.com rdp01.thedomainname.com
RDP         10.130.10.23    3389   RDP01            [*] Windows 10 or Windows Server 2016 Build 17763 (name:RDP01) (domain:hiboxy.com) (nla:True)
RDP         10.130.10.23    3389   RDP01            [-] thedomainname.com\validuser:validpassword

Expected behavior
I expected NetExec to show valid credentials. Logging on via mstsc.exe from a Windows 10 VM using those credentials (and other sets of valid credentials) worked successfully.

NetExec info

• OS: Windows 10
• Version of nxc: 1.1.0 - nxc4u - (latest Git installation as of last week)
• Installed from: poetry

[Marshall-Hallenbeck]

Hey Jeff, does this also fail if you use Linux? It'd be helpful to know to determine if this is a Windows-specific bug, since there's a bunch of weird quirks with running on Windows unfortunately.

Also, the target should go after the protocol and error otherwise, so I'm not sure how it ran... is that a copy-paste of the command?

[jeffmcjunkin]

Yup, it's a copy-paste of the actual command. I can try with latest Kali and report back.

I'm worried it might be due to the licensing status of the RDP server affecting the underlying library (https://github.com/citronneur/rdp-rs), which isn't set up to handle non-activated RDP servers (which still work, and are just in the grace period).

[jeffmcjunkin]

Same behavior with latest Kali and nxc, installed via pipx:

┌──(root㉿kali)-[~]
└─# nxc --version
1.1.0 - nxc4u - 25f0b59
                                                                                                                                                                                                                                            
┌──(root㉿kali)-[~]
└─# nxc rdp 10.130.10.23 -u validuser -p 'validpassword' -d thedomain.com 
RDP         10.130.10.23    3389   RDP01            [*] Windows 10 or Windows Server 2016 Build 17763 (name:RDP01) (domain:thedomain.com) (nla:True)
RDP         10.130.10.23    3389   RDP01            [-] thedomain.com\validuser:validpassword 

(Username, password, and domain swapped out. It's a lab, but not something I want to share publicly)

[jeffmcjunkin]

This may be a red herring, but here's the output when running mstsc-rs from the underlying library:

┌──(root㉿kali)-[~]
└─# RUST_BACKTRACE=full mstsc-rs --dom thedomain.com --user validuser--pass "validpassword" --target rdpserver
thread 'main' panicked at /root/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rdp-rs-0.1.0/src/bin/mstsc-rs.rs:527:51:
called `Result::unwrap()` on an `Err` value: RdpError(RdpError { kind: NotImplemented, message: "Licensing nego not implemented" })
stack backtrace:
   0:     0x55a24313ce92 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hffecb437d922f988
   1:     0x55a24315f24c - core::fmt::write::hd9a8d7d029f9ea1a
   2:     0x55a24313a91f - std::io::Write::write_fmt::h0e1226b2b8d973fe
   3:     0x55a24313cc64 - std::sys_common::backtrace::print::he907f6ad7eee41cb
   4:     0x55a24313e27b - std::panicking::default_hook::{{closure}}::h3926193b61c9ca9b
   5:     0x55a24313dfd3 - std::panicking::default_hook::h25ba2457dea68e65
   6:     0x55a24313e71d - std::panicking::rust_panic_with_hook::h0ad14d90dcf5224f
   7:     0x55a24313e5f2 - std::panicking::begin_panic_handler::{{closure}}::h4a1838a06f542647
   8:     0x55a24313d366 - std::sys_common::backtrace::__rust_end_short_backtrace::h77cc4dc3567ca904
   9:     0x55a24313e324 - rust_begin_unwind
  10:     0x55a243042c95 - core::panicking::panic_fmt::h940d4fd01a4b4fd1
  11:     0x55a243043103 - core::result::unwrap_failed::h5119205a73b72b0d
  12:     0x55a243048027 - mstsc_rs::main::h5af699bc93c4b129
  13:     0x55a243061493 - std::sys_common::backtrace::__rust_begin_short_backtrace::hc33d1773c8808645
  14:     0x55a2430575b9 - std::rt::lang_start::{{closure}}::hb9daaad02326aca9
  15:     0x55a243136bb3 - std::rt::lang_start_internal::h103c42a9c4e95084
  16:     0x55a2430489e5 - main
  17:     0x7fe615b666ca - <unknown>
  18:     0x7fe615b66785 - __libc_start_main
  19:     0x55a243043271 - _start
  20:                0x0 - <unknown>

[NeffIsBack]

Looks like your guess was correct, "notImplemented" error directly from the lib

[Marshall-Hallenbeck]

Okay based on the netexec_debug.txt from Discord I figured it out.

It's an issue when using Kerberos and RDP, on any system, even an activated one (I tested versus an activated Server 2022).

When I check the --debug log, its the same as in the debug log we received.

[Marshall-Hallenbeck]

Also this highlights some annoying stuff about the logging section I updated and stacktraces, I'll need to see if I can fix that as well.

[jeffmcjunkin]

I stubbed out LicenseRequest server packets in a forked commit https://github.com/jeffmcjunkin/rdp-rs, which lets me connect (even though the screen is black). It'll take more to actually support the protocol though.

[jeffmcjunkin]

It's an issue when using Kerberos and RDP, on any system, even an activated one (I tested versus an activated Server 2022).

@Marshall-Hallenbeck : Is it an issue when using Kerberos, or an issue when using a domain account? I'm confused if it's the former. With or without -k and --kdcHost I have the same issue.

[Marshall-Hallenbeck]

It's an issue when using Kerberos and RDP, on any system, even an activated one (I tested versus an activated Server 2022).

@Marshall-Hallenbeck : Is it an issue when using Kerberos, or an issue when using a domain account? I'm confused if it's the former. With or without -k and --kdcHost I have the same issue.

From my side, it looks specifically like a Kerberos issue.
Local user: Works
Admin domain user: Works
Normal domain user: Works
Normal domain user - Kerberos: failure
Admin domain user - Kerberos: failure

[jeffmcjunkin]

Hmm, I still see the issue regardless of local auth, domain auth, or domain auth with Kerberos -- see the attached. Maybe it's two different issues?
netexec further debugging.txt

[Marshall-Hallenbeck]

@jeffmcjunkin do you have another host in the same lab environment you can test against? I've tested against 3 different Windows build #s (14393, 19041, and 20348) with the same results.

[jeffmcjunkin]

Aha! I think it's more of an issue with Remote Desktop Services installed on this machine. Other VMs in the same lab environment have no issue.

I think this code block makes it replicable:

Install-WindowsFeature -Name Remote-Desktop-Services
Install-WindowsFeature -Name RDS-RD-Server
Install-WindowsFeature -Name RDS-Licensing -Restart

[jeffmcjunkin]

Aha! It's replicable! I built two Server 2019 VMs from ISO, and ran the above commands on one of them.

So it's definitely something about being an RDS server.

[Marshall-Hallenbeck]

@jeffmcjunkin are you able to authenticate to that host, or is it just NetExec reporting a failure when it should work?

[jeffmcjunkin]

Yup, I can authenticate to that host using mstsc.exe, the built-in RDP client. Both local VMs have the same credentials.

Same error from mstsc-rs as well:

PS C:\Users\jeff\Downloads> .\mstsc-rs.exe --user sysadmin --pass "Passw0rd" --target 173.31.255.168
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: RdpError(RdpError { kind: NotImplemented, message: "Licensing nego not implemented" })', src\libcore\result.rs:1165:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

[Marshall-Hallenbeck]

I'm installing RDS on a WinServ19 host now so I can debug further