NetExec icon indicating copy to clipboard operation
NetExec copied to clipboard

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

Open jeffmcjunkin opened this issue 1 year ago • 20 comments

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

jeffmcjunkin avatar May 03 '24 13:05 jeffmcjunkin

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?

Marshall-Hallenbeck avatar May 03 '24 14:05 Marshall-Hallenbeck

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 avatar May 03 '24 14:05 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 avatar May 03 '24 14:05 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>

jeffmcjunkin avatar May 03 '24 14:05 jeffmcjunkin

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

NeffIsBack avatar May 03 '24 14:05 NeffIsBack

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).

image

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

Marshall-Hallenbeck avatar May 03 '24 15:05 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.

Marshall-Hallenbeck avatar May 03 '24 15:05 Marshall-Hallenbeck

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 avatar May 03 '24 16:05 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.

jeffmcjunkin avatar May 03 '24 17:05 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.

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

image

Marshall-Hallenbeck avatar May 03 '24 17:05 Marshall-Hallenbeck

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 avatar May 03 '24 17:05 jeffmcjunkin

@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.

Marshall-Hallenbeck avatar May 03 '24 18:05 Marshall-Hallenbeck

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 avatar May 06 '24 16:05 jeffmcjunkin

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

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

jeffmcjunkin avatar May 06 '24 17:05 jeffmcjunkin

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

Marshall-Hallenbeck avatar May 06 '24 18:05 Marshall-Hallenbeck

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.

jeffmcjunkin avatar May 06 '24 18:05 jeffmcjunkin

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

Marshall-Hallenbeck avatar May 11 '24 18:05 Marshall-Hallenbeck

Let me know if I can help here. I still have some local VMs from my own testing that I can share via Discord.

jeffmcjunkin avatar Jul 05 '24 18:07 jeffmcjunkin