RDP module failing to log on using successful credentials to Windows Server with RDS role
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
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?
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).
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)
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>
Looks like your guess was correct, "notImplemented" error directly from the lib
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.
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.
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.
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.
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
-kand--kdcHostI 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
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
@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.
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
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.
@jeffmcjunkin are you able to authenticate to that host, or is it just NetExec reporting a failure when it should work?
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.
I'm installing RDS on a WinServ19 host now so I can debug further
Let me know if I can help here. I still have some local VMs from my own testing that I can share via Discord.