Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jeffmcjunkin opened this issue May 3, 2024 · 18 comments
Labels
bug Something isn't working dependencies Pull requests that update a dependency file

Comments

@jeffmcjunkin
Copy link

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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 NeffIsBack added bug Something isn't working dependencies Pull requests that update a dependency file labels May 3, 2024
@NeffIsBack
Copy link
Contributor

NeffIsBack commented May 3, 2024

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

@Marshall-Hallenbeck
Copy link
Collaborator

Marshall-Hallenbeck commented May 3, 2024

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Author

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
Copy link
Collaborator

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

@jeffmcjunkin
Copy link
Author

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
Copy link
Collaborator

@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
Copy link
Author

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
Copy link
Author

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.

@Marshall-Hallenbeck
Copy link
Collaborator

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

@jeffmcjunkin
Copy link
Author

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 jeffmcjunkin changed the title RDP module failing to log on using successful credentials RDP module failing to log on using successful credentials to Windows Server with RDS role May 6, 2024
@Marshall-Hallenbeck
Copy link
Collaborator

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

@jeffmcjunkin
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working dependencies Pull requests that update a dependency file
Projects
None yet
Development

No branches or pull requests

3 participants