After more than five years of pentesting, I moved onto a management role and this led to meeting even more individuals who desire to transition into pentesting. Almost every time, I was asked “what can I work on to guarantee I will get a job?” The hard truth is nothing will result in a guarantee as I believe there are far more candidates than available opportunities, and the competition gets stronger by the day. Obviously, this is not the kind of answer I like to provide; I do not wish to discourage anyone. Instead, I prefer to focus the discussion on what can make a candidate stand out. Spoiler: there is much more than the technical aspect.

This post contains what makes a difference to me when I am considering a potential candidate working full-time to improve the security of a single large organization, along with some recommendations.

Ideal Candidate

The following are some of the most critical skill sets and mindsets I believe essential to have success in the role.

In-Depth Knowledge of Computer Science

Let’s get the technical part out of the way first since we cannot avoid it.

Take a web application pentest as an example. You will be given a limited timeframe to review its security controls and then present your findings to the software development team. By the end of the pentest, you are expected to know about the application practically as much as the developers themselves, and are going to let them know what they could have done better. That, in itself, is no small task and is quite difficult without knowing much about software development.

In the previous example, does this mean you must have five years of experience in development? Not necessarily but surely, it helps; however everyone learns differently. I have seen some pentesters who only worked as a developer in a three-month internship and it was enough to lay the groundwork to become ridiculously strong at application security. Without a doubt, they spent a considerable amount of personal time learning more about the topic in a self-taught way to get to where they are now. On the other hand, if I look at my own path, I do not think I would have been able to easily transition into pentesting without my four years of full-stack development as they were a critical learning experience. It all depends.

Something else to consider is how you are bound to have new technology you have never heard of thrown at you in a “here, tell me all I have done wrong” kind of way. Then, you will need to become an expert of the technology quickly in order to be confident about what you looked into. This is much easier to achieve when you can rely on your knowledge of the field since you will be able to identify similarities with other technologies you know of.

Excellent Documentation

Now you have found some shiny vulnerabilities, the most important part remains: communication. All the necessary information must be documented in a report to ensure the remediation team gets everything they need to proceed. Precise, but straight to the point to captivate your audience. I cannot stress this enough as any missing or inaccurate piece of information may cause confusion leading to incomplete remediation. Therefore, take a step back, impersonate your audience, and think of what information would be useful to you as the remediator.

Proper reporting also contains a criticality suggestion often guiding how urgent remediation must be done. A common mistake is to have a tendency to blow out of proportion how critical a finding is. This does not help an organization and may mobilize the remediation team on a finding that could have been at the bottom of the list. I get it, you want your findings to be remediated but if any new finding of yours suddenly becomes your talk of the hour, you will lose some credibility to your peers. Again, take a step back, consider the entire context and act accordingly.

Focusing on Value

This one is a favorite of mine. If I hand you five days to work on a project of your choosing, will I be happy of my investment?

A large organization can get a lot of value out of such exercises as pentesters often have good intuition regarding what may be broken, or what could improve their team. Unfortunately, it can also lead to rabbit holes where a lot of time is spent and not much comes out of it; however, I believe it is unfair to expect impactful results every time, and I will never discredit an activity where the motivation had sound reasoning.

As an example, consider the case where a pentester decided to look for some XSS. After a few days, they tell you all about the multiple XSS they found on a web application. Further investigation reveals that the application is only accessible internally, does not host any sensitive information, and is no longer used by any user. In short, the impact is extremely limited. Meanwhile, the pentester has never tested publicly-accessible web applications, cannot tell much about the posture of the organization’s Active Directory/Entra, and has no idea of the effectiveness of “Domain Admins before lunch” type of techniques. That would certainly make me question the investment of time.

In short, consider the big picture before working on a project. It does not mean your idea is wrong, but there are possibly other activities that should be prioritized first. Perhaps you could work on creating a backlog of significant exercises with your team, and challenge yourselves on the priorities.

Key Resource in Special Projects

Whether it is a new large-scale project or an incident response event, the two often share the common factor of having to work without an exact course of action. What I mean by this is you may be brought into these to contribute as the key offensive security expert, and you will have to deal with imprecision. Also, they usually come with an aggressive deadline, so no time to mess around.

These special projects get easier over time as experience pays dividends, but even if it is your first time, you need to be up for the challenge no matter how much it takes you out of your comfort zone. Understand your client, think of what you would want out of yourself if you were in their shoes and plan accordingly. Whatever you will be doing will be much better than freezing and reconsidering your own expertise because it is much different than what you are used to.

As a manager, it is extremely appeasing to know no matter what comes, your experts will be ready to answer.

Peers Feedback & Knowledge Sharing

Everyone can improve, no matter how long they have been in the game. You noticed a situation where your colleague could have done something differently to possibly have a better result? Wonderful! Now, make sure to have an open-minded discussion with them. Maybe there was a variable at play you were unaware of, or maybe you are right it could have been better. All that matters is as professionals, you are expected to have these healthy discussions where everyone can greatly benefit.

Similarly, make sure to be on the lookout for topics that could be shared with your colleagues. Whether it is a new technique, a workflow to be more efficient or a primer on a technology most people are not comfortable with, these will be worth sharing. You want to avoid at all costs a case where every member of the team individually spent some time researching the same subject. How about one member does it and makes a presentation to the team?

Scope & Time Estimates

Most pentests assigned to you will contain two pieces of vital information: the scope (what must be tested) and an estimate of how long the pentest is going to take. Failure to follow the former implies your report will paint possibly a much different picture than reality. Indeed, if you spent time validating the security controls of a different scope, your report might end up claiming the expected scope is clean. In the same vein, if a pentest ends up taking twice as long as initially defined, another pentest will have to be put on hold in the meantime. As mentioned in “Focusing on the Valuable”, it does not mean the extra time you have spent was a waste, but it might not have been the right moment to look into the additional parts.

Making sure to have full understanding of the scope and doing some time checks along the way helps to deliver quality.

My Recommendations

As briefly mentioned in the introduction, there is no way to guide with the guarantee of achieving your goal. Nonetheless, here are a few pointers I believe are important to take into account.

Contribute to a Community

There are plenty of information security communities out there under different forms. Depending on your location and preferences, some may be a better fit but no matter which one you decide to take part of, the outcome is likely to be positive. It can be of benefit both on the technical aspect and to make contacts who may help you get an opportunity eventually. Make sure to bring a positive attitude and to help wherever you can.

Personally, I got my first job in the field through a contact from a community I spent a lot of time with. Usually, it makes the interview process more straightforward, and that is desirable.

Do Not Overdo Certifications

Some people got to the point where they can spell out the entire alphabet with the certification acronyms they have. When I read a curriculum vitae, it does not make much of a difference to me whether someone has three or twenty certifications. Does it mean they are useless? Absolutely not as they are a great way to show you have been working on your goal. If you are having fun catching ‘em all, keep going but do not count on them to be the key differentiator.

Be Good With Code and Web Apps

The idea here is there are different areas of expertise in pentesting itself, but some are more in need. I think it would be a missing opportunity to not be comfortable with web application pentesting as there is usually a bigger demand there, hopefully including code review for better coverage. Even if you are unsure which area is going to be your favorite, it seems adequate to begin with where the most opportunities are going to be.

Do Not Blindly Use Tools/AI

This one can be summarized by understanding what you are doing and why you are doing it. Some seem to be under the impression pentesting is about building an arsenal of tools and then just blindly throwing everything at your target without much consideration. While this can work out in certain scenarios, especially low-hanging fruits, it will never be as effective as someone who understands what those tools do and why they are using them.

Recently, a friend overheard a nearby team at a capture-the-flag event celebrating the flag they had just obtained. When a participant quizzed his teammate on how they managed to solve the challenge, they replied they had no idea because they simply let their AI agent solve it. While any means to an end within the bounds of rules is fair play during a competition, I cannot help but think it would have been much more beneficial for this team of students to focus on the learning experience instead of automagically solving challenges. Enjoy the journey, not just the destination.

Selling Yourself: The “Why You?” Edition

There is more material than ever to learn about pentesting, and surely this results in more people looking for professional opportunities. Time needs to be spent on marketing yourself to successfully stand out of the pack. Consider the section “Ideal Candidate”. How can you show through your actions and accomplishments you possess the characteristics of an ideal candidate? The popular idiom “actions speak louder than words” certainly applies here as it will improve confidence in your abilities to your interlocutor. Feel free to ask your community to review your curriculum vitae and see what kind of impression it makes on them to help you out.

Closing Words

I had the pleasure of meeting many accomplished pentesters and it does not take long to feel how passionate they are. Thus, it is not surprising in any way to find them doing research or getting involved in a community after a long day of work. I am in the belief that anyone willing to dedicate themselves this much into a discipline shall get the opportunity to be an excellent asset for an organization. While I cannot provide a clear path to follow, I hope these thoughts will be helpful in forging your own way.

Recently, I reviewed an implementation of a virtual private network (VPN) server using Azure AD (now Entra ID) as its identity provider (idP), allowing to easily enforce controls such as multi-factor authentication (MFA). The main objective of the assessment was straightforward: manage to authenticate on the VPN without solving an MFA challenge.

This post does not introduce novel or undocumented techniques, but aims to present a methodology to approach a similar problem along with mitigation opportunities.

Basis

Before diving into the analysis, crucial elements will be described.

Setup

In order to reproduce a simplified test environment, the following components were configured:

• Microsoft 365 E5 sandbox with an Azure AD tenant.
• Cisco ASA v9.7+ device running on a private network with the VPN server AnyConnect.
• Cisco AnyConnect enterprise application to achieve SAML-based authentication with Azure AD on the ASA.
• Azure AD conditional access policies applying to various applications and identities.
• Azure AD user with access to the Cisco AnyConnect enterprise application.
• Azure AD-joined Windows 10 device managed by Intune with the Cisco AnyConnect client v4.6+.

The Analyst’s Privileges

In my experience, when it comes to these kinds of assessments or any penetration test, hiding technical details to an analyst accomplishes no good. In fact, it limits the depth at which vulnerabilities may be found, and enables a malicious actor to exploit what was difficultly done in a limited time frame.

As such, the investigation will be conducted with Global Reader privileges.

Expected Authentication Flow

When connecting to the VPN server on the Windows device, the user is prompted to authenticate:

Since user@weakest.cloud has logged into Windows, they have obtained a primary refresh token (PRT) claiming satisfaction for the first factor requirement (you can read about this process here), and can therefore proceed to solving the second factor:

Once this challenge succeeds, the VPN server allows the connection:

Analysis

As previously stated, the goal is to bypass MFA, but the context matters significantly. For instance, depending on your threat model, an ill-intended actor with local or physical access to an Azure-joined device managing to circumvent MFA is likely to be less concerning than achieving the deed with a set of phished credentials, simply due to the vast difference in exposure. This must be regarded when looking for potential vectors.

Sign-in Logs

In a scenario where the interaction between an identity and an application must be inspected, it makes sense to review the user’s sign-in logs and visualize which conditional access policies were applied after authenticating on the application.

Pay attention to the Result column and consider the following: except the policy stating Not Applied, controls in the other two must be satisfied; failure to meet one of these yields access denied. For a primer on conditional access, refer to this article.

Put into words, we can conclude that when authenticating on the AnyConnect application, user@weakest.cloud must solve an MFA challenge and originate from a device deemed as compliant by Intune due to the policies CA200-AnyConnectUsers-AppProtection-AnyConnect-WindowsmacOSLinux-MFA and CA001-Global-AppProtection-AllApps-AnyPlatform-Compliant respectively.

Now, onto reading the pair’s configuration.

MFA Policy

CA200-AnyConnectUsers-AppProtection-AnyConnect-WindowsmacOSLinux-MFA follows the nomenclature suggested by Microsoft which, in return, allows to quickly get an idea of how it is configured, but should be validated concretely nonetheless.

The following can already be seen: it applies to specific users without any exclusion, targets a single application (the AnyConnect enterprise application since it applied to us when connecting), and one category of conditions is used.

Let’s look into the users first:

To facilitate delegation, only the security group named AnyConnect Users appears to handle access to the application, but must be confirmed.

What about the condition?

The policy applies only to users connecting from Windows, macOS and Linux. Does this mean a connection from a mobile device would not trigger an MFA challenge? This will be validated later on.

Compliance Policy

CA001-Global-AppProtection-AllApps-AnyPlatform-Compliant is much simpler:

All users must authenticate from compliant devices to be permitted on applications where Azure AD handles access. Some exceptions exist, like Microsoft Intune Enrollment, where its critical feature of enrolling devices would no longer be possible.

So, the AnyConnect client must initiate a connection from a compliant device to avoid denial. This implies possessing a device managed (enrolled) by Intune and meeting compliance prerequisites; mere device registration would not do the trick.

Validations

This section serves to validate some hypotheses crafted from the previous analysis:

• Users other than AnyConnect Users may have access to the AnyConnect enterprise application.
• Only a specific set of device platforms may be governed by a policy enforcing MFA.
• user@weakest.cloud may be able to enroll mobile devices.

Enterprise Application Access

As only members of the group AnyConnect Users are covered by the MFA policy, two questions arise: do users need explicit access to the application and if so, can more identities access it? These can be easily checked through the Azure portal.

After browsing to the enterprise application, in the properties, the Assignment required? entry dictates whether explicit access to the application is needed:

This is the desired value, otherwise anyone not a member of the group AnyConnect Users would get access to the application without MFA, unless another policy would save the day.

To answer the last question, the section Users and groups lists who can access this application:

This looks good: only expected users are authorized to connect. With that being said, further checkups could be done such as looking into owners and other principals able to control the application, but is left out of this exercise.

Device Platforms Without MFA

The What If feature of conditional access policies is a convenient way to conclude what policies apply when certain parameters are selected. As an example, when setting the test user and the AnyConnect application on a Windows device, the two aforementioned policies are reported as applying:

What if the device is iOS instead?

As previously guessed, MFA is not required to connect to AnyConnect on a mobile device, but it must be enrolled and compliant. A stroll into the compliance policies of the Intune admin center lets on that compliance will not be an issue.

Mobile Device Enrollment

To validate if the user can enroll a device, the same strategy with the What If feature is used, but will target the Microsoft Intune Enrollment application instead:

The policy CA002-Global-AppProtection-IntuneEnrollment-AnyPlatformExceptWindows-Block blocks enrollment of any mobile device, but as its name states, allows all users to enroll Windows devices. Further checks reveal that out of the various ways to enforce MFA, none would apply during enrollment.

Chaining Findings

Operations in the last section confirmed these next statements:

• user@weakest.cloud can enroll Windows devices without MFA.
• iOS devices are not subject to MFA when authenticating on AnyConnect.

Now is the time to trick Azure AD to let us enroll an iOS device and authenticate on AnyConnect without MFA.

My iPad Is A Windows Device

A critical piece of information about conditional access policies filtering on device platforms must be known: they rely on data sent by clients in the HTTP request upon authenticating, and can be altered except when a token with a device ID claim is involved. In the latter case, this claim is used to match the device platform in Azure AD, so no alteration is possible (thanks to Dirk-jan for confirming this); however, no such claim is needed during the enrollment of an iPad device.

Before proxying and modifying the key request, the Company Portal application is installed. After authenticating with user@weakest.cloud and attempting enrollment of the iPad device, the inability is witnessed concretely:

After going back one step in the process, this screen is reached:

At this point, the iPad is configured to use a proxy server, and requests sent by the client are captured. Once the button Continue is pressed, eventually a request to login.microsoft.com will be sent. Two parts of it must be tweaked: the GET parameter x-client-SKU=MSAL.iOS has to be removed, and the User-Agent header needs to match one from a Windows device, for instance Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.19045.

Once the request is forwarded, the user is prompted to download a configuration profile, confirming the policy conditions have been met:

Then, the rest of the process has to be completed normally, which leads to having a compliant device as can be seen in Azure AD:

Authenticating on VPN

All that is left to gain access to the internal network is to install Cisco Secure Client on the iPad and connect to the VPN server:

Similarly to the presented authentication flow, the client was asked to authenticate but with a significant difference: no MFA was demanded. The sign-in logs reflect this:

What About the Windows Device?

The main reason why this bypass was possible is due to the policy enforcing MFA on the VPN applying only to Windows, macOS and Linux. What if from our Windows device, we also change the user agent on authentication to state a different uncovered OS?

In the current setup, as far as I know this cannot be done, simply because the device must be compliant, and compliance validation implies supplying a token with a device ID claim. As mentioned before, this ID is also used to match the device platform, so the user agent is ignored. On the iPad, the user agent was modified while enrolling, not during authentication on the VPN.

Mitigation

In this demonstration, the environment would benefit from adjusting conditional access policies and device platform restrictions.

Do Not Scope on Specific Platforms

Instead of forcing MFA on precise platforms, the weak policy should instead include Any device without exclusions to ensure unknown and unexpected platforms would also be prompted to solve the challenge.

No MFA No Enrollment

When taking the big picture into account, this control neutralizes the biggest threat: compromised credentials used to access cloud applications. Currently, the configuration allows an attacker with user@weakest.cloud’s password to enroll their own device, then browse any application where the only condition is having a compliant device. In the case where MFA is required to enroll, it would instead force the compromission of a device to achieve the same, which definitely requires more effort.

Using Device Platform Restrictions

While I have not fully investigated the complete bulletproofness of this control, Intune offers the possibility to restrict the enrollment of specific platforms for desired principals instead of relying on an easily-bypassable conditional access policy. See the documentation for more information.

Conclusion

Using Azure AD as the idP for cloud and on-premises software is convenient and powerful, but does not avoid complexity especially in large tenants. Conditional access policies can quickly become a mess of loosely scoped conditions and exclusions leading to gaps when a different context is considered. Assessment of these controls in accordance to the identified threats definitely benefit organizations to assure full coverage.

While this post also mentions gMSA for comparison purposes, it aims to document an assessment activity for the standalone version, since it appears to receive slightly less attention despite being the first iteration of the concept.

For more details about MSA, refer to Steve Syfuhs’ excellent post.

A Weakness to Look For

The problem lies in what the sMSA and gMSA can do on a domain. Microsoft specifically mention to enforce the least privileged model:

Why? Let us take the drastic example of an sMSA member of the Domain Admins group. This implies that anybody with control over the computer object where it is installed or with administrative privileges on it could retrieve the credentials of the account, leading to compromising Domain Admins privileges.

The same issue applies to gMSA, but with a potentially higher exposure. Indeed, the msDS-GroupMSAMembership attribute of a gMSA states the principals that can read its password. If any of these principals were to get compromised, the malicious actor would be awarded with the gMSA’s privileges on the domain.

Reconnaissance

Enumerating sMSA

sMSA are typically located in a container named Managed Service Accounts at the root of the domain, e.g. CN=Managed Service Accounts,DC=contoso,DC=com; however, they can be moved elsewhere and also share the location with gMSA.

The most straightforward way to find them is by filtering on their object class msDS-ManagedServiceAccount in an LDAP query:

net ads search -k -S $SERVER '(objectClass=msDS-ManagedServiceAccount)' sAMAccountName

gMSA have the object class msDS-GroupManagedServiceAccount instead.

Identifying Where sMSA Are Installed

sMSA hold an attribute named msDS-HostServiceAccountBL. The BL part stands for “back link”, since it is a linked attribute. This attribute contains the distinguished name of the computer where it is installed. Then, by querying the attributes of that computer object, the forward link msDS-HostServiceAccount can be found, which in return stores the distinguished name of the sMSA.

net ads search -k -S $SERVER '(sAMAccountName=$SMSA_SAMACCOUNTNAME)' msDS-HostServiceAccountBL
net ads search -k -S $SERVER '(sAMAccountName=$COMPUTER_SAMACCOUNTNAME)' msDS-HostServiceAccount

Visualizing Privileges and Attack Paths

At this stage, one must be able to get the full picture of what privileges the service accounts possess on the domain. This requires to collect a bunch of objects and ACEs throughout the entire directory. Then, these need to be mapped in relation to each other so that the analyst can also figure out which objects control the service accounts; perhaps a hint of graph theory sounds adequate. Fortunately, BloodHound does exactly this!

gMSA are well covered in BloodHound. The edge ReadGMSAPassword lets you know about any principal that can read a gMSA’s password (it gets that information from msDS-GroupMSAMembership attribute previously mentioned). Just as any other object, the gMSA’s privileges are gathered in order to draw full attack paths:

Back to the main subject of sMSA. What if we try to get the same information for smsa$? Let us begin with getting the first-degree relationships it has:

MATCH p=(:User {name: 'SMSA$@AD.LOCAL'})-->() RETURN p;

sMSA and gMSA also contain the object class computer, so it is expected to see these as part of Domain Computers. The next relationship of GenericAll over a domain controller is a definite anomaly that should be avoided.

We know that sMSA can only be installed on a single computer, so how about we reveal the computer object that can compromise smsa$?

MATCH p=(:Computer)-->(:User {name: 'SMSA$@AD.LOCAL'}) RETURN p;

Is that so? I quite recall earlier seeing the back link attribute msDS-HostServiceAccountBL stating that smsa$ is installed on CN=WKS1,CN=Computers,DC=ad,DC=local. Further analysis reveals that the installation is functional, and that any principal able to compromise WKS1 could indeed retrieve smsa$’s password.

The issue here is that BloodHound does not currently have an edge to represent a relation between an sMSA and the computer where it is installed, so an analyst cannot solely rely on the tool to assess these.

Finally, first-degree controllers of WKS1 can be queried to obtain a general idea of the sMSA’s security posture:

MATCH p=()-->(:Computer {name: 'WKS1.AD.LOCAL'}) RETURN p;

Apart from the highly privileged groups and the container stating where WKS1 is located, we obtain a valuable piece of information: BRETT_ANDERSON@AD.LOCAL is a local administrator of WKS1.

Dumping sMSA Passwords

After configuring an application to run as smsa$, WKS1 needs a method to get the sMSA’s password to authenticate on the domain.

When an operator enters the credentials of a regular account to run in a service, scheduled task or IIS application pool, they are stored encrypted as LSA secrets on the machine. These can be read by SYSTEM in the registry at HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets, or saved to a file by an administrator using reg save. This is exactly where an sMSA credentials are saved after installation.

Your favorite credentials dumping tool should already implement the functionality to dump and decrypt LSA secrets. For instance, impacket’s secretsdump.py supports it:

python3 secretsdump.py $DOMAIN/$USER:$PASSWORD@$HOST

The first entry of _SC_{262E99C9-6160-4871-ACEC-4E61736B6F21}_smsa$ represents smsa$’s password. The part on the left is its value hex-encoded, while the right shows the plain text. Viewing the plain text makes us understand why it bothered to encode it; using it as a password looks quite challenging. The second entry is the same hex value, but on a single line for convenience.

To use the password, one can calculate its NT hash, then leverage pass-the-hash when authenticating. The following python script can be used to compute the hash:

# nt.py
import sys, hashlib

pw_hex = sys.argv[1] 
nt_hash = hashlib.new('md4', bytes.fromhex(pw_hex)).hexdigest()

print('\n' + nt_hash)

python3 nt.py $PASSWORD_HEX

The credentials can be validated through a myriad of methods, such as calling MS-LSAT’s LsarGetUserName via rpcclient:

rpcclient -U '$DOMAIN/$SMSA%$NT_HASH' --pw-nt-hash -c 'getusername;quit' HOST

To complete the exploitation by gaining privileged access on the domain controller, an attacker would take advantage of smsa$’s GenericAll on the computer object. This allows to perform resource-based constrained delegation.

Final Words

Along with gMSA, sMSA are another source of potential misconfiguration that can lead to domain compromise. As such, this makes them good candidates to look for when assessing a directory. While BloodHound does not currently contain the required information to visualize the full attack path involving an sMSA, an analyst armed with LDAP and Cypher queries can resolve the matter.

To make the analysis simpler, I will propose contributing a new edge regarding this to the BloodHound team.

Recently, I stumbled upon a principal with only DS-Replication-Get-Changes over a domain, which lead to investigating the impact, along with its sibling DS-Replication-Get-Changes-In-Filtered-Set.

This post is dedicated to presenting the consequences of delegating these privileges, and includes a proof of concept PowerShell module to demonstrate the technique for defensive and adversarial simulation purposes.

A Quick Glance at What Can Be Done

• DS-Replication-Get-Changes allows to read the value of confidential attributes.
• DS-Replication-Get-Changes-In-Filtered-Set, coupled with DS-Replication-Get-Changes, allows to read the value of confidential and Read-Only Domain Controller (RODC) filtered attributes, such as Local Administrator Password Solution’s (LAPS) ms-Mcs-AdmPwd.

Describing Concepts

Before we move on, some Active Directory concepts must first be described.

The searchFlags Attribute

The Schema Naming Context, located at CN=Schema,CN=Configuration,DC=contoso,DC=com contains an object for all attributes that can be set on objects found in Active Directory. Just as regular objects, these objects also have attributes set on them, effectively having attributes on an attribute object.

To make sense out of this, let us look at this concrete example.

At CN=ms-Mcs-AdmPwd,CN=Schema,CN=Configuration,DC=contoso,DC=com resides the object of an attribute that you may be familiar with: ms-Mcs-AdmPwd. This attribute is used to store the password of the local administrator managed by LAPS. When viewing its object, we can see some attributes that are either set or unset, and more specifically in our case, searchFlags:

searchFlags (CN=Search-Flags) includes an important feature: it can dictate whether an attribute is to be shown to a user that requests to see its value. Indeed, when the searchFlags attribute contains the flag fCONFIDENTIAL (0x00000080), a user requesting to see the value must have the explicit privileges to read it (RIGHT_DS_READ_PROPERTY and RIGHT_DS_CONTROL_ACCESS).

Going back to our example, since ms-Mcs-AdmPwd’s searchFlags has the flag fCONFIDENTIAL, a user that wants to read the attribute ms-Mcs-AdmPwd on a computer object must have RIGHT_DS_READ_PROPERTY and RIGHT_DS_CONTROL_ACCESS on it; otherwise, the attribute will be returned as empty. By doing so, LAPS ensures that only principals with the right privileges delegated over computer objects can read the attribute.

One last flag supported by searchFlags worth mentioning is fRODCFilteredAttribute (0x00000200). Essentially, this states that an attribute cannot be replicated to a RODC. Note that ms-Mcs-AdmPwd also has this flag, and will come into play later on.

LDAP Extended Controls

LDAP Extended Controls, often simply named LDAP Controls, is a feature that was introduced in LDAPv3. By specifically crafting a request message with an object identifier (OID), a Domain Controller (DC) can be asked to perform a certain set of operations. For instance, the control named LDAP_SERVER_CROSSDOM_MOVE_TARGET_OID (OID 1.2.840.113556.1.4.521) is used to request that a DC moves an object to another domain.

LDAP_SERVER_DIRSYNC_OID (1.2.840.113556.1.4.841)

This control is used to retrieve from a DC any changes made to Active Directory objects since the last time a synchronization was requested, and is the technique that will be used to read the values of attributes with the flags fCONFIDENTIAL and fRODCFilteredAttribute.

The documentation also contains a valuable piece of information: pseudocode of the security check performed when a directory synchronization is requested:

if AccessCheckCAR(msgIn.pNC, Ds-Replication-Get-Changes) = false then
   return insufficientAccessRights
endif
 
if msgIn.pPartialAttrSet.cAttrs ≠ 0 and
   IsFilteredAttributePresent(msgIn.pPartialAttrSet) = true and
   AccessCheckCAR(msgIn.pNC, 
                  Ds-Replication-Get-Changes-In-Filtered-Set) = false and
   AccessCheckCAR(msgIn.pNC, 
                  Ds-Replication-Get-Changes-All) = false
then
  return insufficientAccessRights
endif
 
return 0 /* success */

The Technique

Experimenting With LDAP_SERVER_DIRSYNC_OID

After going through some documentation, interesting points arise:

• .NET’s System.DirectoryServices.Protocols.DirSyncRequestControl is an easy way to request a directory synchronization, and an example script can be found here.
• The flag LDAP_DIRSYNC_OBJECT_SECURITY can be used to request a synchronization without having the DS-Replication-Get-Changes privileges, but only returns attributes that the requester can read. Since we wish to read attributes that we normally cannot, we will avoid sending this.
• An LDAP filter can be specified to only synchronize objects that match it.
• We can also request a specific set of attributes to be synchronized.

Before executing the aforementioned example script, the following has been altered:

• The script handles a cookie to only get the changes made since our last request, but has been removed since this serves us no purpose.
• Filtering is done on (samaccountname=Administrator).
• We only print a few attributes from the response for the sake of clarity, despite requesting all of them.

Add-Type -AssemblyName System.DirectoryServices.Protocols

$RootDSE = [ADSI]"LDAP://RootDSE"
$LDAPConnection = New-Object System.DirectoryServices.Protocols.LDAPConnection($RootDSE.dnsHostName)
$Request = New-Object System.DirectoryServices.Protocols.SearchRequest($RootDSE.defaultNamingContext, "(samaccountname=Administrator)", "Subtree", $null)
$DirSyncRC = New-Object System.DirectoryServices.Protocols.DirSyncRequestControl
$Request.Controls.Add($DirSyncRC) | Out-Null

$Response = $LDAPConnection.SendRequest($Request)
$Attributes = $Response.Entries.Attributes

"samaccountname: " + $Attributes['samaccountname'][0]
"description: " + $Attributes['description'][0]
"objectcategory: " + $Attributes['objectcategory'][0]

Once the executing user has been delegated DS-Replication-Get-Changes, the directory synchronization succeeds:

Without these delegated privileges, the SendRequest function fails, and returns the error message The user has insufficient access rights, as we also saw from the security check pseudocode.

So far so good, but nothing impressive; these can be retrieved with a standard LDAP query.

Accessing Confidential Attributes With DS-Replication-Get-Changes

In the previous searchFlags section, we have established that some attributes are confidential, and cannot be read without having explicit privileges over the object. While some attributes are confidential by default, it is possible to alter existing searchFlags to set some other attributes to confidential, or to create your own confidential attribute.

You can query for confidential attributes like so:

Get-AdObject -SearchBase 'CN=Schema,CN=Configuration,DC=contoso,DC=com' -LdapFilter '(&(searchflags:1.2.840.113556.1.4.804:=128)(!(searchflags:1.2.840.113556.1.4.804:=512)))'

• 1.2.840.113556.1.4.804 is a bitwise OR operator ensuring that we look for the flag fCONFIDENTIAL within all the other flags, and not just this value.
• searchFlags 128 (0x00000080) refers to fCONFIDENTIAL.
• We exclude 512 (0x00000200) indicating fRODCFilteredAttribute, requiring more privileges.

As a proof of concept, the attribute unixUserPassword will be used. It is sometimes used to store a user’s UNIX password hash.

In our example, when querying for this attribute through a regular LDAP query for the user Administrator, nothing is returned, confirming that we do not have the right privileges over the object:

(Get-ADUser -Identity Administrator -Properties *).unixUserPassword

However, if we modify our script to print this attribute, we see that it was indeed synchronized:

Accessing RODC Filtered Attributes With DS-Replication-Get-Changes-In-Filtered-Set

In order to successfully use these privileges, one must also have DS-Replication-Get-Changes, otherwise the LDAP control will deny the request, as denoted in the pseudocode.

Similarly to the last section, we can query for attributes with the flag fRODCFilteredAttribute. We do not need to exclude confidential attributes; we also have the required privileges for these:

Get-AdObject -SearchBase 'CN=Schema,CN=Configuration,DC=contoso,DC=com' -LdapFilter '(searchflags:1.2.840.113556.1.4.804:=512)'

Other than ms-Mcs-AdmPwd, these attributes should all be present in a modern, vanilla installation of Active Directory.

Let us focus on ms-Mcs-AdmPwd. As briefly mentioned in the impact section, this attribute is used by LAPS to store the current password of the managed local administrator, which will either be the default Administrator account, or a custom one.

With our new privileges, we attempt to retrieve the attribute of a LAPS-enabled computer object through a LDAP query, but to no avail:

(Get-ADComputer -Identity wks1$ -Properties *).'ms-Mcs-AdmPwd'

What if we mimic the same procedure as before, and simply print the attribute through our script? The value of the attribute turns out to be empty.

To successfully get the value of a fRODCFilteredAttribute attribute, we must explicitly specify that we wish to synchronize it when constructing the SearchRequest. It can be done by replacing the $null value in the SearchRequest object of our previous script to an array containing the list of attributes, for instance ('ms-Mcs-AdmPwd'), that we desire to fetch.

Once edited and executed again, the password is printed:

If attempting to run this modified script without DS-Replication-Get-Changes-In-Filtered-Set, we will be greeted with the same error message The user has insufficient access rights as before, due to attempting to synchronize a specific attribute with fRODCFilteredAttribute. Again, this is on par with what was written in the security check pseudocode.

DirSync: A Proof of Concept Tool

DirSync is a simple proof of concept PowerShell module to demonstrate the impact of delegating these privileges. It offers two functions: Sync-LAPS to directly focus on LAPS, and Sync-Attributes to synchronize any desired attributes. Usage can be found in the README.md file, and via the usual Get-Help PowerShell command.

A Remark for Blue Teamers

Keep in mind that this technique uses an LDAP request, and not RPC like DCSync. While the tool is designed by default to communicate over plain text for compatibility reasons, it also supports LDAPS. If your DCs have a certificate installed allowing to use LDAPS, do not rely on over-the-wire detection, unless you hold decryption capabilities.

The Wireshark website contains an example capture file of the DirSync control over plain LDAP, filtering on (ObjectClass=*) and requesting no specific attributes.

Some Unorganized Notes

• It might very well be possible to achieve the same result with these privileges using MS-DRSR’s GetNCChanges.
• I did not manage to read secret attributes such as unicodePwd using DS-Replication-Get-Changes-All through the DirSync LDAP control.
• As mentioned in the pseudocode, DS-Replication-Get-Changes-All can be used instead of DS-Replication-Get-Changes-In-Filtered-Set to read RODC filtered attributes. As you can also perform a full-blown DCSync with those privileges, I do not expect DirSync to be the technique of choice, unless it offers some operational security.
• There are multiple ways to track changes in a directory.
• I have not investigated the significance of being able to read the built-in confidential and RODC filtered attributes.

To Conclude

While clearly not as impactful as DCSync, DirSync presents an alternative to synchronize confidential and RODC filtered attributes. The demonstrated LAPS scenario could be used to introduce a new edge into BloodHound, and is a good candidate to look for during Active Directory privileges assessments.

A thank you to @joewaredotnet for the article Replicating Changes Control Access Right series that contributed to my curiousness.

This post is dedicated to presenting the root cause of real-world scenario where if I did not take a close look at the data, I would have documented twice too many users with a path to domain administration privileges. It also includes a proposed solution so that you can also avoid it.

The Questionable Duality of Contains

BloodHound’s Contains edge aims to describe attack paths both from GPOs, and the potential of descendant objects inheriting permissions. Unfortunately, this cannot be achieved without introducing false positives as will be demonstrated.

GPO to Domain Admins

Consider the following path:

The GPO GPO ROOT@AD.LOCAL is linked at the root of the domain, but is not enforced as denoted by the dotted GPLink edge. This signifies that if a domain or OU in the path blocks GPO inheritance, it will not go down to the object that we wish to compromise, which would also be shown in the graph with a dotted Contains edge. Note that this is an entirely different concept than ACE inheritance, and typically does not matter much due to the possibility to enforce the GPO, resulting in a complete disregard of any blocked inheritance. In this demonstration, it is safe to ignore the state of the link, but is worth understanding.

Further down the path, the domain contains the well-known container USERS@AD.LOCAL that itself contains the group DOMAIN ADMINS@AD.LOCAL. Therefore, the Contains edges allow us to map that due to the GPO being linked at the root of the domain, it can use a filter that would apply to the members of the group that we want to compromise.

So far so good; no potential false positive in sight.

ACE Inheritance to Domain Admins

Let us look at this next path:

It is claimed that since the group CL-UNI-ADMINGROUP1@AD.LOCAL has GenericAll over the container where the group DOMAIN ADMINS@AD.LOCAL resides, it can be compromised. The idea would be to create, on the container, a new ACE that applies to descendant group objects, effectively awarding yourself privileges over the group; however, this is simply not possible since Domain Admins is a protected group.

Protected accounts and groups is an Active Directory feature that applies to specific high privileged accounts, groups and their members to ensure that no unwanted principals get privileges over them. An object named AdminSDHolder serves as a permissions template that overwrites protected principals’ permissions every 60 minutes by default. Unless modified, this template has a very important property: it is configured to disable ACE inheritance.

Now, going back to the example above, DOMAIN ADMINS@AD.LOCAL does have ACE inheritance disabled, rendering the path impossible.

This leads to an interesting situation: in the context of a GPO, it is safe to trust the Contains edges, but in the case of an ACE that must be pushed down, they may yield false positives.

How can we successfully use the edge in both circumstances and avoid false positives? By not using it in both circumstances.

Working on a Solution

In the previous section, we have established that any principal with ACE inheritance disabled leads to a false positive when an edge expects to compromise it that way. As such, deleting the Contains relationship would solve the issue, but would also introduce a blind spot in the case of a GPO; nonetheless, it is clear that the relationship is problematic, and must be dealt with.

Finding Disabled Inheritance

When importing the output of the collection method DCOnly into BloodHound, the data set does not include the inheritance state of objects but fortunately, the collector does gather that information, and stores it in the JSON files that are ingested:

Since the desired information cannot be found once imported, it means that the ingesting routine must be modified.

Altering the Ingestor

In the release version 4.2.0 of BloodHound, the file src/js/newingestion.js contains a node creation function for each type of objects located in the JSON files. Since all these objects have the property isACLProtected set in the collected data, we can simply update each function using the same principle that will be shown. As an example, only the buildGroupJsonNew function will be updated.

Before the queries.properties.props.push function call, add the following two lines:

if (properties.distinguishedname !== undefined)
    properties.isaclprotected = group.IsACLProtected;

The if comparison is used to avoid an odd behavior in the JSON where some objects such as groups are duplicated, but incomplete. In that case, they did not contain a distinguished name, so we refrain attempting to set the property. Also, GPOs do not have a distinguished name, and therefore the comparison must not be added in that function.

All that is left is to compile the code. This can be achieved easily using the third-party Docker image electronuserland/builder as such at the root of the edited BloodHound project:

sudo docker run -it --rm -v ${PWD}:/project electronuserland/builder /bin/bash -c 'npm install && npm run-script build'

Once the compilation is complete, the newly created directory BloodHound-linux-x64 contains the compiled binary when using Linux. Execute it and import your data as normally done. Feel free to open up the developer console by using the keys Ctrl+Shift+I to find out if any errors were encountered during the import.

At this point, nodes have the new isaclprotected property set, but relationships must also be adjusted to eliminate false positives.

Reworking Relationships

As briefly mentioned earlier, deleting the Contains edge when ACE inheritance is disabled resolves false positives, but breaks paths from GPOs. Despite this, the edge must be deleted in that situation, so a way to restore paths from GPOs is needed.

Before executing any of the next queries, make sure to either backup your database (if you have the Enterprise version of Neo4j), or to have access to your collected data to avoid any misfortune.

In cypher-shell, execute the following queries:

MATCH (n:GPO)-[:GPLink|Contains*1..]->(m:User {isaclprotected: True}) CREATE (n)-[:DescendsTo]->(m);
MATCH (n:GPO)-[:GPLink|Contains*1..]->(m:Group {isaclprotected: True}) CREATE (n)-[:DescendsTo]->(m);
MATCH (n:GPO)-[:GPLink|Contains*1..]->(m:Computer {isaclprotected: True}) CREATE (n)-[:DescendsTo]->(m);

The idea is to add a new edge, here named DescendsTo, to link GPOs to all objects they can apply to that have ACE inheritance disabled. In a large domain with some GPOs linked at the root of the domain, this may yield a significant amount of newly-added edges, but does not matter much in my experience.

Now that we have linked GPOs to the objects where the path would be lost, we can go ahead and get rid of the Contains edges that are false positives in the case of ACE inheritance:

MATCH (n:Domain)-[r:Contains]->({isaclprotected: True}) DELETE r;
MATCH (n:Container)-[r:Contains]->({isaclprotected: True}) DELETE r;
MATCH (n:OU)-[r:Contains]->({isaclprotected: True}) DELETE r;

On all types of nodes that can contain other nodes, we delete the Contains relationship to the contained node when its ACE inheritance is disabled, successfully removing false positives.

Note that the ingestor could be modified to execute these queries at the end of an import to avoid this manual process.

Validating the Results

After the previous manipulations, the GPO path described at the beginning of this post gets reported as such, but has two negative points:

1. We no longer see where the GPO is linked, and the path it has to take to compromise the user. This could be improved by adding a property to GPO objects depicting where they are linked, or simply query for its GPLink relationships. Then, we can use the distinguished name of the end object to reconstruct the path the GPO is taking.
2. Compromising a principal from a GPO is counted as only one relationship, and therefore risks of being reported more often when using the shortestPath function. Keep in mind that this problem is also true for many other cases, since all relationships have the same weight in the eyes of shortestPath. This leads to a chain of MemberOf costing more than a single ForceChangePassword, despite needing no operation on the domain to leverage the former.

Regardless, in my situation, these downsides are significantly easier to deal with than attempting to manually filter out false positives.

As our last validation, we query for the false positive mentioned earlier:

No path is returned due to the Contains edge getting deleted in the last section, as DOMAIN ADMINS@AD.LOCAL has ACE inheritance disabled.

More Edge Removal

In this section, we diverge from the Contains edge, but remain on the topic of false positive reduction. Depending on your use case, you may be perfectly fine with ignoring the following edges, but in my situation they were problematic.

The GetChanges Family

Prior to version 4.2.0, a singular edge did not exist to identify a principal with DCSync privileges; the analyst had to query for both GetChanges and GetChangesAll. Now, the DCSync edge is created post-processing when the aforementioned privileges are identified. This is convenient, but the GetChanges and GetChangesAll edges are not deleted afterwards, meaning that you may retrieve a path where a principal only has one of them, inducing a false positive.

The same concept applies to the new edge SyncLAPSPassword (technical details available here) combining GetChanges and GetChangesInFilteredSet.

For this reason, during my analysis, I delete the GetChanges* edges, but be aware that this has downsides. Consider the situation where a principal has GetChanges, but not GetChangesAll. If they have GenericWrite on a group that has the missing GetChangesAll, they could add themselves to the group and be able to perform the DCSync. If you delete these edges, you would end up missing this possibility.

If this fits your use case, you can delete the potentially false positive-inducing edges like so:

MATCH ()-[r:GetChanges]->() DELETE r;
MATCH ()-[r:GetChangesAll]->() DELETE r;
MATCH ()-[r:GetChangesInFilteredSet]->() DELETE r;

TrustedBy

TrustedBy simply maps trusts between domains. While useful, it leads to erroneous paths when assessing cross-domain privileges.

Consider the next query and the resultant path:

MATCH p=shortestPath((:User {name: "WILLIAM_STEIN@AD.LOCAL"})-[*1..]->(:User {name: 'LOWPRIVS@AD2.LOCAL'})) RETURN p;

WILLIAM_STEIN@AD.LOCAL has DCSync privileges over the domain AD.LOCAL. Then, AD2.LOCAL trusts AD.LOCAL for authentication, and it Contains the user LOWPRIVS@AD2.LOCAL.

The DCSync and Contains edges are accurate, but the trust mapping acts as if it awards privileges to push ACEs down the AD2.LOCAL domain object, which is absolutely not the case. A trust itself is not enough; WILLIAM_STEIN@AD.LOCAL would need to have been given privileges over AD2.LOCAL to successfully leverage this path.

Although, it is worth noting that this path could indeed exist in the case where the trust has SID history enabled, and that we have the required privileges to forge tickets in the source domain. This should be analyzed independently.

The easiest solution to ensure no false positives result from TrustedBy is simply to get rid of the edges:

MATCH ()-[r:TrustedBy]->() DELETE r;

If need be, you can reimport the *_domains.json file from your BloodHound dump to restore the trust relationships.

Concluding

While the proposed solution has negative aspects, it offers the peace of mind of knowing that the Contains edge will not introduce false positives. As I deem the fix imperfect, I will not be proposing it to the core of BloodHound, but recommend it to anyone assessing privileges at a large scale.

I would like to thank marcan2020 for his contribution to the solution, and the BadBlood project for filling up my directories with plenty of data to play with.

While its interface offers built-in Cypher queries, the full potential of the data set is leveraged by crafting answers to your own questions. In fact, relying solely on the built-in queries can lead to missing critical issues.

Why Learning Cypher Is a Must

Before we move on, one must be familiar with the jargon of graph theory in the context of BloodHound:

• A node or object describes an Active Directory object, such as a User, Computer and OU.
• An edge or relationship links two nodes together. A few examples include MemberOf, GenericAll and Owns.

Now, consider the following case where an analyst wants to ensure that no path exists from one of the groups all users are part of, or a special identity that everyone has such as Authenticated Users. In our specifically-generated scenario, by setting Authenticated Users as the starting node and Domain Admins as the ending one, the interface claims that no path exists:

Under the hood, BloodHound executed this query:

MATCH (n:Group {objectid: "$DOMAIN_NAME-S-1-5-11"})
MATCH (m:Group {objectid: "$DOMAIN_SID-512"})
MATCH p=allShortestPaths((n)-[r:MemberOf|HasSession|AdminTo|AllExtendedRights|AddMember|ForceChangePassword|GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner|CanRDP|ExecuteDCOM|AllowedToDelegate|ReadLAPSPassword|Contains|GpLink|AddAllowedToAct|AllowedToAct|SQLAdmin|ReadGMSAPassword|HasSIDHistory|CanPSRemote|AZAddMembers|AZContains|AZContributor|AZGetCertificates|AZGetKeys|AZGetSecrets|AZGlobalAdmin|AZOwns|AZPrivilegedRoleAdmin|AZResetPassword|AZUserAccessAdministrator|AZAppAdmin|AZCloudAppAdmin|AZRunsAs|AZKeyVaultContributor|AddSelf|WriteSPN|AddKeyCredentialLink*1..]->(m))
RETURN p;

What happens if we edit it to include all relationships, simply by removing the filter?

MATCH (n:Group {objectid: "$DOMAIN_NAME-S-1-5-11"})
MATCH (m:Group {objectid: "$DOMAIN_SID-512"})
MATCH p=allShortestPaths((n)-[*1..]->(m))
RETURN p;

The graph then displays that Authenticated Users has the required privileges on the domain to perform DCSync. This is caused by the missing edges GetChanges and GetChangesAll in the built-in query. Since these two are required to get the DCSync privileges, matching on both of them is mandatory to confirm a path. I believe this cannot be done without greatly complicating the query, and explains why this case was omitted.

Custom queries also help to identify the root causes of issues in a domain. An analysis activity that often yields interesting output is to look at object owners, which will be the subject of the rest of this post.

Querying Object Owners

To begin, we must step away from the interface since we will be dealing with a large amount of objects. Also, we are interested in the relationships of the objects, and not their visual representation. Therefore, querying Neo4j’s database directly through the binary cypher-shell is the way to go.

Consider the following query:

MATCH (n)-[:Owns]->(m)
RETURN n.name, labels(n), count(m.name) AS count 
ORDER BY count DESC;

To explain it simply, we are matching on any type of object that owns other objects, and aggregating results on the count of objects that are owned. The labels function allows to quickly identify what type of object the owner is.

Analyzing The Results

In this analysis, we aim to validate that no principals may escalate their privileges through their ownerships. Indeed, owning an object implies that you may award yourself any privileges on it, and therefore compromise it. The expected configuration would be to have only highly privileged principals owning objects, such as Domain Admins or Administrators.

Already, some thoughts arise:

• Highly privileged principals do own some objects, but not all.
• The data set contains two domains: AD.LOCAL and AD2.LOCAL. While not reflected here, the built-in query to map domain trusts MATCH p=(n:Domain)-->(m:Domain) RETURN p; reveals a two-way trust, meaning that both domains trust each other for authentication.
• There may be some automated process creating objects via service accounts (SA_IAM@AD.LOCAL, SA_SUPPORT@AD.LOCAL).
• BOBFROMACCOUNTING@AD.LOCAL and TEST2@AD2.LOCAL should probably not own objects.
• Any malicious actor with SYSTEM privileges on the computer WORKSTATION.AD2.LOCAL can compromise 168 objects.
• The system administrator SYSADMIN01@AD.LOCAL may be creating objects in the Active Directory, resulting in themselves owning them. This may eventually lead to an escalation of privileges, in the case where an object they created is eventually awarded privileges that SYSADMIN01@AD.LOCAL does not have.

The aforementioned two-way trust brings in potential for further analysis: principals may have privileges in the opposite domain, and could very well lead to cross-domain ownerships.

Investigating Cross-domain Ownerships

In the database, all objects contain an attribute named domainsid. This helps to quickly identify what domain the object is part of, and is especially useful when investigating cross-domain privileges.

See the following query:

MATCH (n {domainsid: '$DOMAIN_SID2'})-[:Owns]->(m {domainsid: '$DOMAIN_SID1'})
RETURN n.name, labels(n), count(m.name) AS count
ORDER BY count DESC;

Notice that it is nearly identical to the previous one we ran, except we are filtering on domain SIDs. The goal is to get the count of objects AD2.LOCAL owns from AD.LOCAL.

So, it turns out that WORKSTATION.AD2.LOCAL and TEST@AD2.LOCAL ownerships are only located in the AD.LOCAL domain, while a subset of owned objects by DOMAIN ADMINS@AD2.LOCAL are also there.

Understanding the Impact

At this point, we can scope our analysis on understanding the impact of owning other objects. More precisely, in this example, we will look at paths leading to the compromise of the opposite domain.

Depending on your knowledge of a domain, you might understand the implications of compromising certain principals, even if they do not directly possess the required privileges to compromise the entire domain. Focusing on these key principals is usually as valuable as evaluating the paths to Domain Admins; however, in order to remain configuration agnostic, the next operations will use Domain Admins as the pot of gold, but may be replaced with any key principal.

The next query will be executed in the interface:

MATCH (n {domainsid: '$DOMAIN_SID2'})-[:Owns]->(m)
MATCH p=shortestPath((m)-[*1..]->(:Group {objectid: '$DOMAIN_SID1-512'}))
RETURN p;

• MATCH (n {domainsid: '$DOMAIN_SID2'})-[:Owns]->(m)
  • Matching on all objects of AD2.LOCAL that own objects from any domain.
• shortestPath((m)-[*1..]->(:Group {objectid: '$DOMAIN_SID1-512'}))
  • Starting from the m variable defined in the previous match, which represents objects owned by objects of domain AD2.LOCAL, we look for any relationship within any amount of hops that leads to the Domain Admins group of AD.LOCAL.
  • The path is wrapped in the shortestPath function in order to return only, as it states, the shortest path. This is important, since a query like this in a large domain can be extremely expensive computing-wise.

The results signify that some currently unknown object from AD2.LOCAL owns the group BE-199-DISTLIST1@AD.LOCAL that has a path to DOMAIN ADMINS@AD.LOCAL through the ForceChangePassword edge. Fortunately, we already know the recipe to query who the owner is:

MATCH (n)-[:Owns]->(m {name: 'BE-199-DISTLIST1@AD.LOCAL'})
RETURN n.name;

At this point, we must further investigate who else has control of the computer object WORKSTATION.AD2.LOCAL within the same domain, but will be left out of this exercise; though, it is already concluded that a domain administrator of AD2.LOCAL is a few hops away from administrative privileges in AD.LOCAL, by hijacking the computer object.

More Cross-domain Fun

Throughout this example, we focused on a single direction to assess privileges (from AD2.LOCAL to AD.LOCAL), but remember that we are dealing with a two-way trust. What if an object from AD.LOCAL can compromise WORKSTATION.AD2.LOCAL? This would yield a path starting from AD.LOCAL to compromise an object of AD2.LOCAL, and then use those privileges to become a domain administrator of AD.LOCAL.

We can query all objects from AD.LOCAL that have direct privileges on WORKSTATION.AD2.LOCAL like so:

MATCH (n {domainsid: '$DOMAIN_SID1'})-->(m {name: 'WORKSTATION.AD2.LOCAL'})
RETURN n.name;

Make sure to query for only one hop, since this avoids the case where objects with indirect privileges are shown.

There we have it, TAMERA_ARNOLD@AD.LOCAL has a path to DOMAIN ADMINS@AD.LOCAL by compromising WORKSTATION.AD2.LOCAL. This can be seen in the graph, simply by setting TAMERA_ARNOLD@AD.LOCAL as the starting node, and DOMAIN ADMINS@AD.LOCAL as the ending one:

TAMERA_ARNOLD@AD.LOCAL has GenericWrite over the computer object, and therefore can compromise it through resource-based constrained delegation.

Reporting

Now that we have some findings, we must properly document them to ensure a successful remediation. This step is as critical as the assessment activity itself; what is the point of observing issues if we do not report them adequately?

Despite needing to understand the inner workings of how an Active Directory is configured to be able to tell if some object ownerships are abusive or not, for instance the IAM service account owning objects, it is more than adequate to document your theories, or at least observations so that administrators can confirm if they are intended or not.

In this scenario, I would document the following:

• All paths leading to domain compromise from objects that should not have any privileges.
• Suspicious ownerships, even if they do not currently lead to further escalations, e.g. BOBFROMACCOUNTING@AD.LOCAL, TEST@AD2.LOCAL and SYSADMIN01@AD.LOCAL.
• A CSV file containing all ownerships, unless the file would end up being ridiculously large.

We can easily generate this by slightly altering our first ownership query to include the object SID:

MATCH (n)-[:Owns]->(m) 
RETURN n.name AS Owner, n.objectid AS `Owner SID`, m.name AS `Owned Object`, m.objectid AS `Owned Object SID`

Then, we can use the procedure apoc.export.csv.query to directly export the output in a CSV file, which will be located under /var/lib/neo4j/import/ on Ubuntu:

WITH "MATCH (n)-[:Owns]->(m) RETURN n.name AS Owner, n.objectid AS `Owner SID`, m.name AS `Owned Object`, m.objectid AS `Owned Object SID`" AS query
CALL apoc.export.csv.query(query, "ownerships.csv", {})
YIELD file, source, format, nodes, relationships, properties, time, rows, batchSize, batches, done, data
RETURN file, source, format, nodes, relationships, properties, time, rows, batchSize, batches, done, data;

Note that the procedure is not installed by default. Refer to this article for installation.

You may also write a query to avoid exporting objects owned by highly privileged principals such as Domain Admins, unless they are located in a different domain. This would greatly reduce the potential noise in the export.

Conclusion

In this post, we experimented with a methodology to investigate object ownerships across domains. By harvesting the power of custom Cypher queries, the data set is manipulated to scope on specific issues, then reused to extract information to help the remediation.

I hope this will convince you that using Cypher during a BloodHound assessment is mandatory, and will inspire you to develop a technique to investigate more scenarios.

In the Windows world, this activity has countless layers due to the complex nature of Active Directory, and the myriad of protocols willing to answer specific questions requested by any domain user.

Typically, when one seeks to get a good context of a domain privileges-wise, they instantly think of BloodHound and I absolutely agree, but is there an alternative?

Often, I found myself in situations where I was given a scope of 10 to 20 Windows hosts. While BloodHound supports the -ComputerFile argument to collect information from specific hosts, it feels like there is quite a bit of overhead to answer particular questions, such as “who are the local administrators?” and “what users are logged in?”. In that case, I had to rely on various enumeration tools here and there, without ever feeling like I could get it done efficiently, and more importantly, thoroughly.

This has lead to the development of WinRemoteEnum.

What is WinRemoteEnum?

WinRemoteEnum is a module-based collection of operations achievable by a low-privileged domain user, sharing the goal of remotely gathering information of Windows hosts, and their hardening status on commonly-leveraged techniques.

Since most is enumerated through exposed built-in MS-RPC methods, it is heavily based off impacket.

Execution

When executing the tool, domain credentials and targets will be required as minimal input. If a list of modules is not given, all will be executed. Once the enumeration has completed, the results/ directory contains another directory matching the timestamp at which the execution has taken place, and stores easy-to-consume HTML and JSON enumeration result files.

python3 winremoteenum.py -u $USER -p $PASSWORD -d $DOMAIN $TARGET

As this is the bare minimum, ensure to read the --help for possible parameters and options.

Module users

This module is without a doubt my favorite, and the main reason behind the development of the tool. Prior to this, I did not have an efficient and easy-to-parse way to enumerate local users, groups, and their members from hosts. Thanks to MS-SAMR, this is indeed possible from a low-privileged domain user on hosts, as long as access to the SAM Remote has not been hardened.

Use Case: Basic Reconnaissance

Before digging into the host, I like to get a general idea of its context by browsing the users.html file. Quickly, you should be able to tell if it is properly maintained or has gone through years of misuse, simply by looking at the local users and groups, and then answering some questions as such:

• How many local users does it have?
• Is the entire cosmos a local administrator?
• Are SIDs getting resolved by the DC, or the users and groups most-likely no longer exist?

Use Case: Analysis of Remote Access Groups

I use the term “Remote Access Group” to refer to any group allowing a user to compromise a host remotely, whether the end result is a privileged access or not.

The newly released version 1.1 of WinRemoteEnum contains an analysis script that can be ran manually by a user, resulting in a list of members of the groups in question. This yields a map of which users must be compromised in order to gain access to the host, or if you are able to leverage previously-compromised users.

python3 analysis/users/analyze.py results/$RESULTS_DIR/json/users.json

Visit the wiki for usage information about the script. Do note that some techniques are using services bound on different ports, meaning that proper firewalling may block you from accessing the host.

In the next section, each remote access group will be explained.

BUILTIN\Remote Management Users

This group provides access to Windows Remote Management (WinRM).

On Windows, PowerShell Remoting allows to leverage this easily by using Enter-PSSession or Invoke-Command.

On Linux, CrackMapExec includes a nice implementation, which can be used like so:

./cme winrm $HOST -u $USER -p $PASSWORD -d $DOMAIN -x $COMMAND

BUILTIN\Remote Desktop Users

If the Remote Desktop Services are started on the host, simply fire up your favorite Remote Desktop client, and authenticate on the host to gain access.

BUILTIN\Distributed COM Users and BUILTIN\Performance Log Users

When running the analysis script, these groups are listed as “potential” since they do not grant access to the host out-of-the-box, as opposed to the other groups.

If you wish to learn about these groups and the additional privileges required, you can read about it in my previous post Non-administrative DCOM Execution: Exploring BloodHound’s ExecuteDCOM, or note that you will need Remote Launch and Remote Activation over the DCOM object that you want to instantiate.

impacket’s dcomexec.py can be used to perform the object instantiation:

python3 dcomexec.py -object MMC20 -silentcommand $DOMAIN/$USER:$PASSWORD\$@$HOST $COMMAND

BUILTIN\Administrators

This is evidently the Holy Grail of groups, allowing to gain privileged access to the host using the aforementioned techniques, or a multitude of different ones. For instance, impacket additionally offers atexec.py, psexec.py, smbexec.py, and wmiexec.py.

If you require to execute commands as the user instead of NT AUTHORITY\SYSTEM, use dcomexec.py (ensure to supply the -object MMC20 parameter), or wmiexec.py.

Modules sessions and logged_on

These two have been grouped due to usually sharing the same goal: hunting users to dump their NT hash.

sessions enumerates net sessions established on a target. A net session is created when a client accesses a target’s resource remotely, such as a network share.

On the other hand, logged_on returns users logged onto a target by enumerating registry keys through the Remote Registry service.

Use Case: Basic Reconnaissance

As goes for most modules, I begin with browsing the sessions.html and logged_on.html to get a general idea of what is happening on the host.

Many sessions might very well indicate a file server that has significant traffic. Combined with a writable network share, one may be able to leverage NTLM relay.

Additionally, logged on users can help understanding the purpose of the host, and how it is used.

Use Case: Hunting Users

In the results of sessions, the source field indicates where the user has initiated the connection from, meaning that in the case where this user has authenticated on this source using a protocol that caches NT hashes in the LSASS process, a privileged user may leverage credential dumping.

Regarding logged_on, similarly to sessions, the users may have authenticated on the target using a protocol that caches their NT hash.

When looking for the location of a specific user, I suggest simply using the grep command on sessions.json and logged_on.json, and see if you get any results back.

Module shares

The shares module offers precisely what it states: a view of the network shares available on a host through SMB, and if the executing user can read them. It also lists the name of the first-level files and directories. In the case where the count of items exceeds __MAX_SHARE_LIST_ITEMS (currently 30), a total of files and directories will be reported instead.

The tool currently does not report whether the user has write access due to the possibility of polluting the share. You can read about it in the wiki.

Use Case: Basic Reconnaissance

The shares.html file quickly shows the state of the host shares-wise, and how many of these can be read.

Use Case: Finding Sensitive Information

Network shares are often a successful vector to get initial access on a host, either by getting your hands on some credentials, or through NTLM relay when they are writable.

Since the first-level content of shares are listed, this is a convenient way to identify at a first glance which ones might be worth digging into.

Module host_info

This module is dedicated to reporting information about the host, such as its OS version, role, domain, SMB hardening, and if the executing user is a local administrator.

Use Case: Basic Reconnaissance

Similarly to other modules, host_info.html helps to understand further the context of the host, by revealing information regarding the OS, and more.

Use Case: Local Administrator Privileges

By attempting to open the Service Control Manager (SCM) database with all privileges, one can conclude remotely if they have administrative privileges on the host.

This can be seen in the local_admin field.

Use Case: Finding NTLM Relay Targets

To successfully relay a NTLM authentication on a target, it must have SMB signing disabled, which otherwise validates that the message has not been tampered with.

The smb_signing_required field denotes this.

Audit

WinRemoteEnum offers an auditing feature, accessible simply by providing the -a parameter. This will report if the enumeration vectors have been hardened against low-privileged users, since most of them are indeed hardenable.

Head over to the audit section of the wiki for a description of what is audited for each module.

Learn More

Make sure to go through the README and the wiki for information about optimization, credentials validation, reporting, modules, auditing, and analysis.

When analyzing a BloodHound graph, one may see from time to time an edge where a user or group can compromise a host via ExecuteDCOM, described as the following:

This can allow code execution under certain conditions by instantiating a COM object on a remote machine and invoking its methods.

What are these certain conditions, exactly?

The Non-administrative Possibility

In a blog post about BloodHound version 2.0 by Rohan Vazarkar (@CptJesus), it is stated that the edge ExecuteDCOM is newly introduced, justified by the possibility that a member of the BUILTIN\Distributed COM Users group may be able to instantiate objects remotely:

The ExecuteDCOM edge runs from a user or a group to a computer and indicates that the principals are part of the Distributed COM Users local group on the target system. Depending on the security descriptor on the target system, users in this group sometimes have remote code execution privileges without corresponding administrative permissions on the target system. This provides another lateral movement method that does not require administrative access. Collection of this edge belongs to the new DCOM collection method.

This changes the impact of the technique from “I can execute code because I have all privileges” to “I can execute code when people might not expect me as able to”. We also learn more about the conditions: they are security descriptors.

So, what if we were to attempt to instantiate one of those convenient objects offering a method with code execution?

Tracking It Down

The following operations have been performed on a domain-joined Windows 10 host.

Validating the Default Behavior

To begin, impacket’s dcomexec.py was used to achieve object instantiation remotely, providing credentials of a domain user having no particular privileges:

python3 dcomexec.py -object MMC20 -silentcommand -debug $DOMAIN/$USER:$PASSWORD\$@$HOST 'notepad.exe'

• -object MMC20 specifies that we wish to instantiate the MMC20.Application object.
• -silentcommand executes the command without attempting to retrieve the output. This is desirable since the script is using an SMB share to write and fetch the output, and our low-privileged user cannot write to any.
• notepad.exe is ran on the target as a simple proof of concept.

RPC access denied. This is expected as currently, the user is not a member of the BUILTIN\Distributed COM Users group, and therefore cannot call MS-DCOM’s IRemoteSCMActivator::RemoteCreateInstance.

This can also be seen from Wireshark:

Then, the user is added to the BUILTIN\Distributed COM Users group, which yields a different error but not from RPC itself:

This confirms that only having access to the group is not enough, and that we have already reached the point where these descriptors must be investigated.

Leveraging Windows Events

Before chanting a spell to summon a vile creature from the abyss in hopes of compromising the integrity of your soul to obtain, yet again, a glimpse of answer regarding obscure Windows behavior, paying a visit to the Event Viewer may be worthwhile.

In this case, it was indeed quite insightful:

So, Remote Activation permission issues. Further testing revealed that Remote Launch privileges were also missing.

Looking Into DCOM Security

Tuning DCOM security appeared to be quite the task until reading another of Matt Nelson’s blog post. In the “Defenses” section, he discusses the possibility of restricting DCOM access to local administrators by removing their Remote Launch and Remote Activation privileges, and goes in depth explaining how to concretely achieve this.

Simply put, DCOM objects can be configured in two ways: either they follow system-wide security configuration, or their own. Therefore, the member of BUILTIN\Distributed COM Users also needs to have been given Remote Launch and Remote Activation privileges according to the object’s configuration, which is not the case out-of-the-box for the MMC20.Application object as demonstrated above.

By default, the MMC20.Application object follows system configuration. Once Remote Launch and Remote Activation is given system-wide to the group BUILTIN\Distributed COM Users (I suppose this is a mistake that could be seen in the wild), we test the same command as before:

The instantiation worked and our command was executed, which I confirmed by seeing that notepad.exe was running on the host as our executing user.

About Other Objects

ShellWindows and ShellBrowserWindow

These two built-in objects are also known to offer command execution capabilities. As the instantiated objects offer an interface to Explorer.exe, the command will be executed as the logged on user and therefore should be avoided, since a non-administrative user will most-likely not be able to run commands as them.

Custom Objects

Keep in mind that other than the built-in objects, a user could have been given privileges over a custom object that may offer methods capable of code execution; however I am unaware of any decent way to investigate these without having local access on the host, which usually defeats the purpose of attempting to find a way to pivot on it.

Another Group: BUILTIN\Performance Log Users

A member of the group BUILTIN\Performance Log Users will essentially get the same privileges as BUILTIN\Distributed COM Users, meaning that they will also be able to call the RemoteCreateInstance method. Remote object instantiation will be possible, as long as they have been given the Remote Launch and Remote Activation privileges.

I believe that this is much less likely that a member of this group will also have the aforementioned remote privileges on a relevant object, but worth noting that it is possible.

To Conclude

I do not expect this technique to be possible very often in the wild as a non-administrator due to the extra remote privileges required on the objects, but it is interesting to observe another misconfiguration in the Windows world that has significant consequences.

Food for thought: since I could not find a way to tell if my user had the required privileges over an object other than by attempting to create the instance, and since the system logs quite well that a user has attempted to do so, some might like the idea of creating a honeypot in your domain where some key principals are reported as having the ExecuteDCOM edge on a host.

As an internal pentester, I have always found it difficult to stick to the old-fashioned idea that your job ends after a report has been written; however, to be quite frank, I understand it due to the politics that are often induced from stepping outside of your boundaries. Nonetheless, understanding the big picture of the information security initiatives in your organization is extremely valuable, with an input that should help steer the ship in the right direction.

Often, it feels like the Groundhog Day when it comes to prioritization. Either these concepts have to be recalled to various people in an organization due to the lack of singular orientation, or they must be reminded as new information security managers or projects arrive. For these reasons, I have decided to write down some thoughts to solve my own problem, and perhaps to distribute them to whoever deems as relevant.

So, if I want to improve my organization’s security posture, what should I be working on and most importantly, what do I prioritize?

Expectations

This article will address the question of structuring the initiatives of the so-called red, blue and purple teams, and may be seen as scoping into the technical aspects of information security. We will not be looking at the governance of establishing for instance security standards, risk analysis and acceptance, or a security software development life cycle.

However, this does not mean that security governance teams should not be involved in any of this. In fact, they may be responsible for budgets or projects, depending on your organization’s structure, and be your greatest allies to communicate the needs to the upper management.

The Terminology of the Rainbowesque Teams

A few terms will be explained to make sure that no confusion arises, since these sometimes have different definitions.

Red Team

Depending on whom you speak to, this term englobes any offensive security discipline from internal and external pentesting to adversarial simulation. For this reason, I will use the term “Adversarial Simulation” for any initiative that aims, using tactics, techniques and procedures (TTPs), to test the detection abilities and responsiveness of an organization. “Red Team” shall be used to allude to a team that works on the offensive side of information security. Note that by “offensive”, I refer to the idea of performing defense by offense, which usually implies finding issues before the adversaries do.

Blue Team

To remain consistent with the above, a “Blue Team” will refer to any area that focuses on the defensive side, from vulnerability management to threat hunting.

Purple Team

Simply put, a “Purple Team” is a collaboration between the aforementioned teams in order to work jointly on the ultimate goal of protecting the organization. An example of exercise is to perform TTPs in absolute transparency, while the defenders build detection use cases.

Disclaimer

I will never claim that this is the sole approach to the question, nor that I have experienced and seen it all. Undoubtedly, the wonderful world of information security is rarely black or white (great, more colors!). Despite this, I believe this article will present a strong strategy that should apply to most organizations that face the problem of securing their and their customer’s information.

Furthermore, some security products will be mentioned to assist solving issues, and I am in no way affiliated with these companies. Also, it must be understood that deploying a tool by itself will practically never solve a problem, unless the dedicated resources possess the proper skill set to operate it and analyze its output.

The Basis

Approaching a problem of such complexity is imposing, to say the least. Fortunately, the information security field includes countless talented individuals who have already pondered upon the question, and generously published their work. It is mostly a matter of finding this information through an ocean of buzzwords and snake oil, along with identifying the truly experienced and successful.

DerbyCon 2018: “Victor or Victim? Strategies for Avoiding an InfoSec Cold War”

At a first glance, this quality talk given by Jason Lang (@curi0usJack) and Stuart McIntosh (@contra_blueteam) seems to only address the relationship of the red and blue teams, but much more is shared. In fact, a single slide will be the entire basis of this article. I thank them for their great work.

The Slide

The idea shared by Jason and Stuart is simple: both the red and blue teams must climb steps synchronously by implementing these practices, starting from the bottom. This synchronization requires to never lose focus of how the other party is doing, otherwise a complete mismatch of maturity will be induced. Your red team may be eager to perform adversarial simulation engagements but if the blue has just started to deploy an Endpoint Detection and Response (EDR) product, you cannot expect them to be able to grow out of the conclusions of your engagements, simply due to not having access to proper tools to monitor the environment.

By laying out clear steps with categories of initiatives, this can be used whether your organization has just started their security program or has been investing into one for quite some time. A team that understands well the current maturity of each of these can quickly identify what needs to be worked on, and most importantly in what order.

The rest of this article will be dedicated to offering a concrete example of how these touchpoints can be shaped for an organization, with hints on how to approach them, as well as how to view the steps in general.

Defining the Rules: When do I climb a Step?

The answer depends entirely on the context of your organization and requires designing your own rules, which are likely to be challenged during each step. By “context”, I refer to internal politics, budgets, technical debt or inventory issues, to name a few. Surely, the experts of your red and blue team must be brought in to be the judges and designers of the said rules.

Any sizeable organization can face issues that increase the improbability of ever completely mastering a category, for reasons out of control of the colored teams. Should the experts be chasing perfection at the expense of going forward? Should they instead channel their creativity and engineer solutions that could perhaps improve the posture, nonetheless?

Remember that fleet of servers which hosts a critical business application and no longer receives security patches due to being out of support? The source code has been lost and the sysadmins have been unable to migrate it to modern servers. Therefore, it will have to be rewritten from scratch, which will take longer than you can afford. This can be seen as a flaw in your patch management process, since you expose an attack surface that cannot be addressed. What if you were to monitor the logs, develop use cases or implement an EDR instead of not going forward because your patch management is flawed? However, do not get me wrong: in no way does monitoring a host and installing an EDR replace the need to install security patches, but it may help you out in the case of a non-sophisticated actor.

Speaking of threat actors, knowing the step that you are at can help identify what degree of sophistication your organization is mature enough to defend against. For instance, patch management and network controls may be successful against an unsophisticated actor. A properly configured EDR and centralized logging would help for a pentester-level actor, who would be seen as performing actions without perfect operations security. Tuned alerting and threat hunting could aim at defending against a nation-state actor. With this in mind, if your organization has started to work on an initiative targeting a sophisticated actor and you know for a fact that an automated attack would be successful, it might be time to reprioritize.

Shaping the Touchpoints

As all organizations should, I have taken the time to analyze the touchpoints and to shape them to match what I believe would be the best for, in this case, a large organization that has publicly accessible endpoints, and will expect to deal with a significant count of vulnerabilities. Most of the steps remain the same, as the original touchpoints already made a lot of sense.

Other than small alterations to reflect the terminology defined above, the “Network controls” category has also been moved a step higher, alongside implementing an EDR. The reasoning behind the changes is the following: any sizeable organization that deals with vulnerabilities will need to implement a vulnerability management process and team, otherwise the likelihood of correcting (if ever) the wave of vulnerabilities found by scanners and the red team in reasonable timeframes is practically nil. Regarding your publicly available endpoints, not monitoring them is a recipe for disaster. All steps will be explained in further details in their respective sections.

Do not hesitate to add more steps, or even to expand the current steps into smaller ones, if judged appropriate.

Now, onto comments and hints regarding each step.

Step One

Vulnerability Scanning

This practice involves implementing an automated scanner into your network to identify vulnerabilities. As the tools are often configured to authenticate on your assets, they can dig into configurations and find out what is not adequate security-wise. In fact, they are good at identifying missing patches, misconfigurations or compliance issues, while the most aggressive web-oriented ones might even find a SQL injection here and there.

Depending on the complexity of your network and number of assets, vulnerability scanning can go from quite easy to implement, to requiring an entire project to manage its deployment. This practice is found at the first step due to the findings usually being the low-hanging fruits.

Quickly, you will be asking yourself countless questions, such as:

• How often should I be scanning?
• Do I really need to scan every single networking asset?
• What about workstations of employees working remotely? (hint: look into agents)
• What are the odds of taking down a critical server? (it happens)
• Who will be responsible of the scanners’ health?
• When and how do I patch my scanners?
• How do I whitelist my tool’s IP address when scanning external assets?

These will need to be discussed and analyzed in great details, and some answers definitely depend on your patching capabilities.

Nowadays, there are countless commercial and non-commercial products, with the former focusing on operating efficiently in large environments. The tools that I have seen the most successfully deployed in corporate environments are Nexpose from Rapid7 and Nessus from Tenable. Much must be taken into consideration when choosing the right tool, such as their ease of integration into your environment, their efficiency and coverage, their reporting abilities, and of course pricing. I highly advise to perform proof of concepts by deploying a few scanners that seem to fulfill your needs, to see how they truly react and what they find. Do not hesitate to deliberately plant vulnerabilities into some systems (non-production in a segregated network, please!) that will be scanned to find out if they will be identified.

No amount of vulnerability scanning will ever replace a pentest but it is not rare to see a pentester perform this activity to quickly identify the most obvious, which could also help orientate their operations.

Do not forget to quickly work on a plan to scan your publicly reachable assets. If your scanner identifies vulnerabilities, it implies that a malicious actor may be able to leverage them.

Now that your tools found vulnerabilities, what’s next? The harsh reality of dealing with scan results will be discussed in the vulnerability management section.

Patch Management

Unfortunately, this step is far from trivial, yet it is the first one on the blue side. I view patching as the foundation of information security, which justifies implementing its management early.

A vendor has worked on a fix for a vulnerability, either self-identified or from an external researcher, and has shared it with its consumers. Now, all that is required is to install it! Definitely easier said than done in environments that have been plagued by legacy systems out of support.

This gets even more complex when a wide range of operating systems (OS) are in use, since they often use different tools to manage patches. Each of your organization’s OS will need to be analyzed to find out what would be the best strategy to patch them, and what product(s) to use.

Then come potential inventory issues which may become the bane of your existence. Your vulnerability scanner might start scanning countless assets that you never knew existed and won’t even know when these can be safely rebooted after patching (when patch application requires it), once introduced into your new patch management tool. This should be taken into account when building your patch management process.

If unable to patch systems for various reasons, a case needs to be built and brought up to management, in order to create new projects. These will often require projects, since it is extremely unlikely that some resources capable of working on a fix will get enough time in their day-to-day responsibilities to work on this, unless scoped in a project.

Vulnerability Management

I have added vulnerability management to the first blue step due to the fact that I have observed countless times in the past that a strong vulnerability management team and process is mandatory as soon as you deal with a large organization. Otherwise, you will find out that a ton of reported vulnerabilities are not going to be fixed any time soon, since there might be no security standard in your organization that requires an asset owner to do so. Even communicating the information to the owners may be a challenge when no team is dedicated to doing so.

Armed with the results of the newly implemented scanner, the vulnerability management team shall unleash a fury capable of causing many nights of insomnia to the CISO. With this imagery, I refer to the impressive count of vulnerabilities that may be reported by your tool. Before anything, the results need to be properly analyzed since these tools tend to be extremely verbose. For instance, you will often find out that a single patch can fix hundreds of vulnerabilities on a host. Also, false positives are very much a possibility.

I have often found myself completely incapable of properly analyzing any results without having access to the scanner’s database where I could perform my own SQL queries. That way, I was able to filter out any noise, and find out what should be addressed first. As an example, I would query for vulnerabilities that are not related to patching due to those being addressed by patch management eventually, which would lead to finding some gems even more critical.

Since vulnerability management is much more than simply looking at scanners’ results, a solid process must be built. This team also needs to know the organization quite well, or at least have a good understanding of the asset owners, which will be confirmed when the pentesting team starts reporting vulnerabilities on many different hosts.

Here are a few questions to help building your process:

• Once reported, how long does an owner have to fix? Is the time length strictly related to criticality?
• What happens when an owner refuses to fix or exceeds the time limit?
• Can the red team document vulnerabilities efficiently or does the process prevents them from doing so?
• How do I handle duplicates? What should I do when a vulnerability is spread on thousands of assets?
• How do I track the status of all these vulnerabilities?

The team also needs to have a good understanding of the vulnerabilities that are reported and their impact. In fact, they must be given the power to reprioritize vulnerabilities once analyzed. Pentesters often get little to no context of the environment where they have found a vulnerability, which can lead to miscalculating the criticality.

It is without a doubt that a tool dedicated to vulnerability management must be implemented, which has to be flexible enough to work with your process. I encourage you to engage into proof of concepts of various options, once your process has been built.

To end this section, here is a wonderful tweet by Andrew Robbins (@_wald0):

Step Two

External Pentesting

This step aims at finding any way of exploiting or harvesting data from outside of an organization’s internal network, under the reasoning that automated tools and actors are constantly scanning for vulnerable assets from the leisure of their basement, which justifies implementing it before internal pentesting.

Your team must ensure to get access to a list of assets that are known to be accessible publicly. When hosting internally, inventories or firewall rules can hand out this information. If unavailable, there are various open-source intelligence tools that can help at the task, such as Amass and Shodan. The use of cloud providers will complexify this, but strategies such as domain/subdomain enumeration (Amass does this) and TLS certificate indexing may work.

Once the targets have been acquired, things become a matter of performing traditional pentesting and harvesting the power of task automation when dealing with a large quantity of assets. Make sure that your pentesters get access to your vulnerability scanning tool so that they can add new targets to scan schedules or view results.

When a vulnerability has been identified, testers must be able to communicate these results quickly and easily, so that your vulnerability management team can start analyzing and prioritize accordingly. Hopefully, your vulnerability management process has already solved this in the previous step.

If your organization does not expose assets publicly, do not view this as a free pass since a lot can be done nonetheless. Here are a few examples:

• What information can be enumerated about the organization? Does an employee leak the entire security product suite on their LinkedIn profile?
• Did a developer commit closed-source code or credentials on GitHub?
• By sifting through data breach databases, can I find an employee’s credentials? Does this employee still use this password somewhere in the organization?
• Can I easily manipulate an employee to run malware through phishing? Will your email filters and protections catch known malware?
• Do email headers leak any valuable information that could be leveraged by a malicious actor?

External Endpoints Monitoring

When the red team conducts external pentesting and successfully exploits vulnerabilities, are their operations being noticed by anyone? If not, does it mean that if an external adversary were to get a foothold on your server, no one would find out?

Under the same train of thought that finding publicly exploitable vulnerabilities should be prioritized over internal ones, it makes sense to monitor your external endpoints first. However, the concept of “internal” vs “external” may seem to blend in when you are under the impression that your internal network is much more likely to be breached through phishing. After all, all it takes is an educated actor and a few clicks from one employee. Because of this, I would not necessarily disagree with the initiative of implementing an EDR first on workstations, or at least work on both at the same time, especially if you have absolute confidence over your external assets’ security (make sure that your pentesters confirm this).

Your monitoring solution can involve installing an EDR (which is also planned for next step but at a larger scale) on your endpoints and/or working on use cases. Despite not having centralized logging yet, forwarding and aggregating these logs in a single console where use cases are developed only for your external assets is crucial. Forwarding is mandatory since it gives you a chance to detect an attacker before they are aware of your logging solution and start altering the local logs.

The current pandemic surely has brought in more appliances exposed publicly, usually for VPN-like features. These will need to be opened up, analyzed and modified to be monitored accordingly. I was surprised while working on Citrix NetScaler’s CVE-2019–19781 to find out that an organization’s web logging retention was 7 hours. This does not help much when you are trying to identify whether a potential breach may have occurred a while ago. And again, if these logs are not forwarded anywhere, how can you confirm their legitimacy?

Step Three

Internal Pentesting

Let us make something clear right away: if you are constantly trying to make your pentesters work in the same conditions as a malicious actor, you will lose. By this, I refer to the thought that pentests must be conducted in a black box way, where the testers don’t have access to source code or a server’s configuration. Reality is that a pentester will have a few days to break into your web application, while an adversary could spend a lifetime. Therefore, your testers will need to work in utter efficiency without having to constantly justify their actions and deal with the occasional “Why would I give you access to the server? Aren’t you supposed to break in?”.

Your organization probably has a role dedicated to something along the lines of guiding projects with an information security-aware advisor. These advisors should be encouraged to request pentests when they have judged them valuable. I would not be surprised if they already have a list of applications or environments that should be tested. Make sure to prioritize according to the attack surface and exposure. If you find out that a new web application built in-house is about to be deployed externally, feel free to catch and test it before it is publicly available.

When it comes to what should be tested first, I like to focus on what is likely to be attempted first by an adversary that would get a foothold into your network. In an Active Directory environment, there are various well-documented techniques which are often successful and, for this reason, very likely to be exploited. You don’t want an actor to get in through phishing, simply launch BloodHound, find out that their compromised user can authenticate with administrative privileges on a server, pivot there, do credential dumping since NTLM authentication is used, get access to a service account and just keep digging into your network that way.

As suggested per the infrastructure case described above, a practice that I find valuable is conducting non-scoped pentests. While highly effective, especially if you encourage your team to work together on a potential chain of exploit, this must be seen as a great privilege and no reckless operations must be attempted (I’m looking at you, ARP spoofers) unless a resource can confirm it cannot have a negative impact. I suggest getting a written approval from your CISO to ensure they are aware of this practice’s existence, and to help out in the case where those spoofers judged it adequate to poison entire subnets.

The External Pentesting section briefly stated the importance of communication with the vulnerability management team. In fact, before the first internal pentest report is written, I highly recommend agreeing on a reporting standard that both teams will be comfortable with. When the structure is the same from report to report, it is much more convenient both for analysis and when a retest is conducted.

Endpoint Detection and Response (EDR)

By itself, a properly configured EDR should fend off unsophisticated actors and definitely annoy any pentester who has not taken the time to work on their tools. This is where the defenders will start seeing operations performed during pentests (on the infrastructure side, that is). Generally, I would say an EDR yields great results monitoring and blocking-wise considering the efforts required to configure and deploy.

Regarding what assets the EDR should be installed on: if there is a system on your network and it is compatible with your solution, go ahead and install your EDR on it. Yes, your development environment also needs to be monitored since they tend to have a lot more than just non-production stuff on there.

As you might already expect, before a large-scale deployment is done, seeing how the EDR behaves into your environment is mandatory especially when it offers features that will block any process that it judges as malicious. It is not entirely impossible that your sysadmins have some funky ways of administrating servers or scripts that could be blocked. Once you are pleased with the configuration, feel free to let your pentesters have a go in case something turns out to be too permissive.

There are two products that I’ve had the chance to experience and see in action. The first of them being CrowdStrike Falcon that offers a feature called Falcon Overwatch, which claims to have a team that performs threat hunting on the logs gathered by the EDR. As a quick anecdote, after performing a privilege escalation on a server that involved running a custom C# reverse shell, this feature eventually raised an alert because the process chain and the network connections between the two subnets were unusual. A pleasant surprise to say the least.

The second product is Microsoft Defender for Endpoint. As opposed to CrowdStrike, this one has a feature called Microsoft Defender for Identity, which has detection capabilities over Active Directory attacks such as kerberoasting, ticket forgery and password spray. However, the conclusion was that it required considerable tuning in order to deal with the false positives.

Network Controls

This section and “Administrative Rights” were moved on par with internal pentesting simply because the pentesters are likely to identify some these in their regular activities. If you are confident you can find these without your pentesting team, feel free to put them back a step before.

Network controls are a big deal and I will kick this off with one of Lee Christensen’s (@tifkin_) tweet:

How healthy is your network segmentation strategy? Is it a flat network, which implies that your workstations can reach any pot of gold without having to pivot through the network? Is there a magical subnet that makes it possible to reach any other subnets? Not only proper segmentation makes it tough from a technical aspect to move further as explained by Lee, but it also improves the odds that a malicious actor will end up making a mistake and reveal their position in your network. Pair up with network architects and see how your strategy could be improved.

Another initiative could be to look into what vectors can be used to communicate or exfiltrate data to an external command and control server. Is the network configured in a way where as soon as you get on a server, they will gladly initiate HTTP, ICMP or DNS requests egress?

This step also brings in the opportunity to look at your network shares, which many organizations have issues with due to years of misuse. A scan authenticating with your regular, non-privileged domain user should quickly give you an idea of how much sensitive data you can get your hands onto, or even service account credentials that have been left off in a configuration file. Your vulnerability scanner may also have a plugin that reports network shares.

Administrative Rights

An operation that I love to perform when I get into a new environment is to run a quick BloodHound scan in Domain Controller-only mode (so that I don’t become the new hire who starts querying every single computer in the domain). This gives you an idea of what the domain looks like and if it turns out that every single user is a few hops away from DCSync privileges. Depending on how big your domain is, a resource could be dedicated for a while to deleting relationships that turn out to have excessive privileges.

Then, you have the service or sysadmin accounts and how they are used. Can these accounts authenticate on various servers using NTLM, which suddenly provides a way for an actor to pivot if they have access to dumping the lsass process? Or perhaps some sort of UNIX-based equivalent, where password authentication is used through SSH and then any attacker with system call monitoring privileges would get the password in clear text? Limiting your privileges, using Local Administrator Password Solution (LAPS) and public-key authentication can assist solving these.

Last but not least, workstations and servers must be assessed to make sure that they are not vulnerable to trivial privilege escalations. Elevated privileges always unlock new vectors that can be used by an adversary and also act in a stealthier way.

Step Four

Purple Team

To quickly reiterate what has been mentioned in the terminology section, a purple teaming activity is defined by the red and blue team becoming one to solve problems regarding detection and processes.

Since this is where the blue will start forwarding and aggregating logs in a centralized database, the timing is adequate to develop use cases. As more and more logs are available to work with, this is a good opportunity to build your coverage of the TTPs contained in the ATT&CK framework. These have been identified from real-world threats and are therefore techniques that are concretely leveraged by malicious actors. Each of the techniques also mentions in which data sources you can aggregate and build your use case on to detect it.

Both teams must meditate and decide what techniques should be covered first. A good starting point could be to see how to detect techniques typically applied in a domain as described in the internal pentesting section, if the required logs are available. Make sure that you don’t try to catch the most sophisticated actors first. Also, this framework offers matrices built per OS, which you might find useful if you would like to focus on a specific OS first, perhaps the most widely used and more likely to be exploited. Do not overwhelm yourselves with attempting to cover too many techniques in the matrices, as this should be done once your centralized logging is mature.

Once completed, now is the time to perform these TTPs and by looking at the documentation on each technique, see how you can build a use case that would work in your environment, assuming that you do have access to the proper logs.

Other than covering TTPs, any questioning puzzling the blue team can be brought up during this activity to brainstorm an appropriate solution.

Centralized Logging

This is where the architecture of your network and infrastructure in general may come to haunt you. Can your network handle the extra load of forwarding logs at a decent interval? Can your archaic data aggregation tool scale with the influx of logs? Despite these potential issues, this step is mandatory to build detection use cases.

You will be required to build a strategy to collect the logs of various systems in your environment, which are your input for use cases. Precisely what logs need to be collected depends entirely on the TTPs that you desire to detect. For instance, the prioritized techniques that have been pinpointed in the purple teaming exercise will orientate the needed logs. The matrices will also give you a heads up on the following techniques, so that you can plan the collection ahead and fix any issues that may arise.

As a hint, your EDR vendor may be able to provide you a list of TTPs their product covers, which implies that you could build use cases covering other techniques (make sure to validate that your EDR really covers what they say).

Step Five

Adversarial Simulation

Now that we have centralized logging, developed use cases, and are working our way through the ATT&CK matrices, we need to validate how these would be handled if detected in a real-world scenario. Will these techniques be detected and reported properly in the day-to-day operations? How will the analysts respond? Are the response processes well-defined and optimized? Will the investigation stop after the containment of a machine, when the attacker has had enough time to pivot elsewhere? This is what adversarial simulation aims to validate and, as opposed to purple teaming, it happens unknowingly to the analysts and responders.

When establishing the scope and which TTPs should be used, feel free to brainstorm with members of the blue team, as long as they will not be responding to your actions. In fact, you need some of the blues to be aware of the exercise to make sure that, for instance, a critical business server does not get rebuilt if a threat from the exercise is detected on it.

It must be stated that simulating a highly sophisticated actor at this step using TTPs not covered by any use case has little to no value, since the conclusion is already known to the blue team. However, using an unmonitored technique is justified if its entire purpose is to place the operators in a situation where they will be able to perform actions that will test detection mechanisms currently in place. I have also seen the case where the level of sophistication simulated was at the highest, as a last resort to secure funding by proving that your organization can be breached (ah, politics!).

At the conclusion of an engagement, do not hesitate to plan a purple team exercise so that both teams collaborate on solving the identified issues.

Implementing and structuring an adversarial simulation practice in your organization is complex and deserves its own book. Luckily, a great one has already been written by Joe Vest (@joevest) and James Tubberville (@minis_io) named “Red Team Development and Operations”. I highly recommend it.

Finely Tuned Alerting and Response

Other than covering more TTPs, you must ensure at this point to develop impeccable alerting. If your analysts start to ignore a use case because it ends up being a false positive, it must be corrected. Also, this is the step where conclusions of adversarial simulation engagements are analyzed and addressed.

You can also look into your developed cases with members of the red and find out the amount of effort that would be needed to bypass some of these, and adjust accordingly. Is it trivial or would it require complete knowledge of how the detection is built? This could be done in an adversarial simulation engagement or a purple teaming exercise, but feel free to structure this in any way that makes sense, and, most importantly, in the most efficient way.

The information security field is in constant evolution. When it is not a researcher that published their findings, a new APT may act in a clever way that ends up being a blind spot in your detection use cases. Keeping up with these is required when your organization has achieved a level of maturity where it is able to do so.

Step Six

I have not had the chance yet to experience this section in an organization that was truly mature enough to properly implement these. However, these two practices were existent, or at least teams did claim to do precisely that, but since the steps below were not brought up to fruition, they had to spend most of their time working on lower steps.

Non-scoped and Long-term Adversarial Simulation

The highest level of sophistication is simulated in this practice and the idea is the following: without having a specific scope or time limit, your operators will stealthily get multiple footholds in your network, and proceed in the best operations security they can. To avoid getting caught on aggregation, they might decide to let an implant sleep for weeks at a time after performing an action, or even longer if it is planned to be leveraged only in the future.

Then after a while, an implant may be sacrificed knowingly or by mistake. Will the blue team manage to put the pieces of the puzzle together, and perhaps find more implants or reconstruct how this one has gotten access to the system? Will your threat hunting team find your implants in their day-to-day operations?

It is without a doubt that both teams will train each other, either by having the blue share how the red’s operations security was flawed, or how the red managed to remain undetected to the blue. This collaborative relationship is necessary in order to achieve a growth capable of detecting the most sophisticated attacks.

Threat Hunting

Proactivity is a key component to threat hunting. This team will not rely on your built detection use cases and will instead focus on the idea that an actor has managed to breach and not raise any alert. They will still be good consumers of your centralized logs and will build their own queries to analyze the data.

This assumed breach model involves looking for indicators of compromise that have fallen through your detection mechanisms, either by your non-scoped adversarial simulation exercise or an actual threat. In fact, this practice has the best probability of identifying a sophisticated actor that would for instance, compromise your environment through a supply-chain attack using custom malware, and slowly dig through your network in operational security. This would not be caught by your typical use cases and instead requires an extremely knowledgeable resource who understands how these actors operate.

The practice is brought in at the end due to the fact that it relies on the healthiness of the initiatives beforehand, as true for most steps. If your environment is still facing issues that makes it extremely noisy and near impossible to investigate, which allows even the least experienced threat actor to operate in peace, you do not need threat hunting.

To Sum it Up

Experts of both the red and blue team must ensure that they share the same vision on the “what” and “how” of prioritization, and work together to avoid maturity differences. Guidelines are made to do exactly what they say: offer lines of guidance. Therefore, a critical overview of your organization depends entirely on understanding well its context, a mandatory prerequisite to having educated thoughts on how to approach these issues in your environment.

I encourage every organization to fully engage into the exercise of building their own steps of offense defense touchpoints, by collecting input from all the information security professionals.