Yesterday, I wrote a thread describing the ESXi vulnerability and how you can use BloodHound's Attack Path Management approach to quantify the impact of such a group. However, it's useful to understand our exposure to the vulnerability as well.
https://x.com/jaredcatkinson/status/1818314447238386109

To gain this understanding, we must explore which principals have the requisite rights to either create a group with a specified name or rename an existing group. This is an attack path question as rights are expressed as edges in the graph.

In order to evaluate exposure, we must first understand which rights are necessary in order to perform either variation of the attack (create or rename). Once we understand those details, we can attempt to use the graph to find users who have those rights.

My colleague @Jonas_B_K dug into this problem to identify the required rights, here's what he found:

To create a Group, a principal must have one of the following rights on an AD Container:
• CreateChild (either scoped to the Group class not scoped)
• GenericAll

In order to rename a group, a user must have the Write permission to the group's cn and name attributes. This permission can be obtained via the 
• Write access to the Public-Information property set
• GenericWrite
• WriteProperty (any attribute)
• GenericAll

It wouldn't be an attack path conversation if we didn't talk about ways in which attackers could grant themselves Write permissions. This can be done if they have any of the following permissions:
• WriteDACL
• Owner
• WriteOwner

Now that we know the details, we can begin to query our BloodHound graph to see what we find. Unfortunately, the current BloodHound model does not include all of the necessary rights, but we can get a partial picture by focusing on the GenericAll and GenericWrite edges.

Of course it's Lord Varys that has the ability to sneak users into the ESXi cluster (sorry @bakedsec).

Again, GenericAll & GenericWrite are not the "least necessary rights" for the renaming scenario, so this result should be considered a subset of the true results.

To close the gap, Jonas wrote this PowerShell script to enumerate principals that can create groups or rename existing groups within a domain.

NOTE: This script depends on the ActiveDirectory PowerShell module which is installed on DCs by default.
https://github.com/JonasBK/Powershell/blob/master/Get-CreateRenameGroupACEs.ps1

Once you've installed the ActiveDirectory module and Jonas' script, you can run it using the commands shown in the screenshot below.

NOTE: These commands enumerate both scenarios, creation and renaming. You can focus on one by commenting out the undesired section of the script.

Here's an example of the output which specifies principals that can rename (first set of results) or create (second set of results) a group and thus implement the vulnerability:

For those that love to dig through the details, you can get the specific Access Control Entries for an object as shown below. Notice the CreateChild and WriteProperty Rights in the result. Those are important!

I encourage you to consider the big picture lessons that we can take away from this specific example. Even if you don't use ESXi, this is a case study that describes the impact of attack paths & how easy it can be to lose control of the permission model.

This scenario stands out by leveraging what's absent instead of what's there. That's why only a fraction gets modeled in BH. An implicit right assignment from ESXi to a potentially non-existent group springs to life once the group is created. Such cases are rare and intriguing.

Analyzing ESXi Vulnerability with BloodHound's Approach

Yesterday I shared this thread on per-user services. You all responded with corroborative data from your environments, so I wanted write this thread highlighting your findings.
https://x.com/jaredcatkinson/status/1712517132205044225?s=20

@Kostastsale shared some tactical ideas on how to approach exploring the Service landscape in your environment.

https://twitter.com/Kostastsale/status/1712580335790444673?s=20

@JimSycurity shared this breakdown of the different values that can be passed to the dwServiceType parameter of CreateServiceW. Notice the decimal value 128 (0x80) which labeled PROCESS_INSTANCE. This is a flag that is set to indicate a per-user service (e.g. 0xe0 and 0xd0).

https://twitter.com/JimSycurity/status/1712567717528502733?s=20

@Cyb3rMonk

97.81% per-user service instances

https://twitter.com/Cyb3rMonk/status/1712540369022546060?s=20

@JayInfoSec

99.72% per-user services over 30 days

https://twitter.com/JayInfoSec/status/1712551011758518420?s=20

@lawndoc

91.55% per-user services over 30 days

https://twitter.com/lawndoc/status/1712554075940966665?s=20

@nef0sf

90% per-user services

https://twitter.com/nef0sf/status/1712726400136864226?s=20

@olafhartong

91.23% per-user services over 30 days (85k machines)

https://twitter.com/olafhartong/status/1712777787700892094?s=20

@fabian_bader

95.35% per-user services over 30 days (~25k machines)

https://twitter.com/fabian_bader/status/1712740237862916427?s=20

@lystena

89% per-user services over 30 days (20k machines)

https://twitter.com/lystena/status/1712802256507330702?s=20

Exploring the Service Landscape in Your Environment

🧵 Did you know that 90-95% of all service creations are benign and relatively simple to exclude from detection? Allow me to share some insights about per-user services and what we have recently discovered.

In Windows 10, Microsoft introduced a feature called Per-user services. These services are created when a user logs on and deleted when the user logs off, allowing them to run in a user context instead of system-wide.

For more info, follow the link: https://docs.microsoft.com/en-us/windows/application-management/per-user-services-in-windows)

A brief review reveals that default builds of Windows 10 include approximately 20 different per-user services. As a result, 20 new services are created with each logon session. This can create significant noise for those attempting to observe service creation events.

Upon reviewing the earlier shared document page, we can observe that there is a per-user service named "UnistoreSvc". One might assume that each logon session would have its own UnistoreSvc, but unfortunately, it's not as straightforward as that. It never is...

On Windows, it's not possible to have 2 services with the same name. However, a single system can have multiple active logon sessions simultaneously, which creates a conflict. To address this issue, the locally unique ID (LUID) is appended to the name of the service instance.

If the logon session's LUID is 0x54afd0, then the UnistoreSvc instance will be named UnistoreSvc_54afd0. This presents a practical challenge for those who want to stack services based on their names, as each per-user service has a distinct and unique name.

In a domain environment, user logons happen frequently. Just imagine how many per-user services are generated in your environment if 20 services are created EVERY time someone logs on. It would be great if we could safely exclude these services from our search results.

This implies that if we can find a secure method to filter per-user service instances, we can significantly alleviate the burden of detecting service creation. Interestingly, I had previously attempted to solve this problem, but in a highly naive manner.

In a previous blog post, I created a list with known per-user service names and then attempted to split all services on an "_" character. If the first element of the split array matched a name in the array, then I filtered it.

Read more about it here: https://medium.com/specter-ops-posts/thoughts-on-detection-3c5cab66f511

At the time, I was aware that this approach had a significant blind spot. Attackers could easily exploit it by creating a service w/ a name that followed a specific template: "<name of service>_<random 6 hex characters>". By doing so, their service would be filtered out.

In the post, I even said, "The approach I used to exclude [per-user services] is fairly basic and could be bypassed by an intelligent attacker, but for the purposes of this experiment, that is an acceptable risk." However, at the time, we didn't have a better way to filter them.

Imagine my surprise when I scrolled through a list of services and noticed that all the per-user services had strange values in the Service Type field. I observed that EVERY per user service had a Service Type value of either 208 (0xD0) or 224 (0xE0).

I thought I had a good understanding of how the Service Type field operated. I was aware that it was provided through the CreateService* API, and that there were specific values outlined in the documentation. It's worth noting that 0xE0 and 0xD0 are not among the defined values.

So, we began digging, and initially, @harmj0y stumbled upon a random Github gist that suggested that 224 (0xE0) is a combination of 0x80 (INSTANCE), 0x40 (USER), & 0x20 (SHARE_PROCESS). This indicated that the Service Type enum had two undocumented bits.
https://gist.github.com/ye0nyu/83fcd7bc161cf43a27d610adaad3fae9


How common are these services? @Praga_Prag conducted a non-scientific evaluation of a production network and found that per-user service instances (0xD0 and 0xE0) represent ~95% of all service creations. This ratio was consistent across all networks that we checked.

@harmj0y then discovered an insightful blog post by @HelgeKlein that shed light on the topic.

You can find it here: https://helgeklein.com/blog/per-user-services-in-windows-info-and-configuration/

According to Helge, per-user services have two components: the template and the instance. When there is a need to run a service within the context of logged-on users, the vendor MUST first create a TEMPLATE with a Service Type of 80 (0x50) or 96 (0x60).

When a logon session is created, the Service Control Manager enumerates per-user service templates and generates instances for each one within the context of the logon session. These instances inherit the name of the template and include the Logon Session LUID.

This implies that if the template is named "PrintWorkflowUserSvc" and the Logon Session Locally Unique Identifier (LUID) is 0x34ad02, the instance will be named "PrintWorkflowUserSvc_34ad02."

With a deeper understanding of Service Type values, we can identify per-user services better. However, it's crucial to test if an attacker can initiate a service using these types. Otherwise, our knowledge may not be as helpful as expected.

Will and I attempted to run some quick tests in order to create a custom per-user service without first creating a template. However, despite making multiple attempts, we were unsuccessful.

I came across a subroutine in services.exe (the MS-SCMR RPC server) called "ScCreateUserServicesForUser" that seems to handle instance creation. It seems to use CreateServiceW in a similar manner to our attempt, so it might be worth investigating its parameters.

[Offensive Call to Action] If you are a red teamer and have made it this far, we would highly appreciate any assistance you can offer in testing our, tentatively held, hypothesis that creating per-user services without a preceding template is not feasible.

[Defensive Call to Action] We'd love to gather data to support this conclusion on a wider scale. In general, we recommend evaluating Service Creation Events and grouping them based on the Service Type.

We are specifically interested in the ratio between per-user service instances (0xd0 and 0xe0) and "normal" services.

Insights on Per-User Services in Windows 10

🧵 
1/ In a previous thread I introduced an idea I call function call graphing. The goal is to represent all of the ways that an adversary could achieve a specific action (Process Read in this case) through APIs. Let's talk through one potential defensive use case.

2/ The idea for function call graphs actually came about in the wake of the MITRE EDR Evaluations. The evaluation protocol and subsequent interpretation of results by vendors caused me to become hyper focused on identifying a measurable way to evaluate detection coverage.

3/ I knew that there were many ways in which attackers could alter their tools to cause it to appear different while still achieving the desired behavior. In many cases, it's not practical or even possible to test EVERY variation which means we MUST select a subset of variations.

4/ The problem with selecting a subset of variation is that it isn't obvious which subset you should choose. We have a tendency to measure our tests quantitatively (we have 7 Kerberoasting tests), but not qualitatively (we choose these 7 tests because...).

5/ Testing is extremely important in detection engineering and purple teaming to ensure that detection rules are meeting their goal. The problem is that there isn't much rigor used in selecting which variations to test.

6/ In my experience, the selection process involves identifying common or novel implementations and integrating them into the testing framework. This isn't a terrible strategy, but it leads to the common error where the set of tests is more similar than different.

7/ Consider these images. Imagine that the outer circle represents the scope of possible iterations for a behavior & the purple circles represent our test coverage. Both include the exact same five purple circles, yet we can see a substantial difference in overall coverage.


8/ These images reveal to us the idea that some subsets of possible iterations provide more optimal coverage than others. For instance, when it comes to OS Credential Dumping: Lsass Memory there are many known tools that we might use as part of our test.

9/ Imagine having the option of choosing between 2 sets of implementations for this behavior. The 1st set includes mimikatz & Invoke-Mimikatz while the 2nd set includes mimikatz & Out-Minidump. Which would you choose? I'd choose the 2nd set because the options are MORE different.

10/ You see, Invoke-Mimikatz is basically just a wrapper that injects mimikatz into memory. This means that besides the mechanism of code execution, they are functionally equivalent. Out-Minidump on the other hand uses a completely different API function to achieve its objective.

11/ Let's take a look at a function call graph for the Process Read action. This shows all of the KNOWN functional paths that applications can take to read the virtual memory of a process. Notice that using this graph it is fairly easy to see that Out-Minidump is more different.

12/ Okay, so it seems there might be some utility in using these function call graphs to find the more optimal set of test implementations, but can we find the MOST optimal set? If so, can we calculate it mathematically instead of using our intuition?

13/ Take a moment to consider how you might answer this question. Each red circle is an entry point into the graph and all paths are directional. That means there are eight different options. If you were asked to select the 3 most optimal starting points, which would you choose?

14/ Now that you've committed, let me tell you the methodology that I've found for answering this question. As mentioned above, it seemed obvious to me that given the choice between mimikatz & Invoke-Mimikatz vs. mimikatz & Out-Minidump the choice would be Out-Minidump, but why?

15/ The only explanation I could find in my head was that mimikatz & Out-Minidump seemed more "different" or "dissimilar". Maybe that was enough to start searching for answers. My first question was whether it was possible to measure the dissimilarity of paths in a graph.

16/ It turns out that there is a way to answer this question. I found a discussion on research gate¹ about this topic. This paper² explains that a simple way to measure path similarity is to use "edit distance" measurements. 
[1]https://www.researchgate.net/post/What-is-the-metric-to-find-if-two-paths-in-a-directed-graph-are-similar
[2]https://www.sciencedirect.com/science/article/pii/S0893965907001012

17/ Edit distance (ED) is a way to quantify how dissimilar two strings are. It counts the minimum number of operations that are required to transform one string to the other. This is useful in many applications such as spell checking, DNA analysis, & malware naming.

18/ Levenshtein distance is the canonical ED algorithm and measures three types of operations:
Deletion (D) - sv_host -> svChost
Insertion (I) - sEvchost -> svchost
Substitution (S) - svRhost -> svChost

19/ Okay, so ED is used to measure the number of operations it takes to convert one string to another, but we aren't dealing with strings... we're dealing with paths in a graph. Well what if we converted each path into a string and then compared them? Seem simple?

20/ Using this idea we can convert each node to a letter and then create strings for each possible path. For instance, the path that starts at kernel32!MiniDumpWriteDump (this is the path Out-Minidump uses) would be ADFGH. The path used by ntdll!NtReadVirtualMemory would be GH.

21/ We can then calculate the string for every possible path by analyzing all paths starting at nodes with red borders. This analysis results in 8 possible paths, shown below:
ADFGH (Out-Minidump)
DFGH
FGH
GH
H (dumpert)
BEFGH
EFGH
CEFGH (mimikatz)

22/ A key feature of ED is that it is used for 1 to 1 comparisons, not 1 to many. Therefore, it is important we select a starting path to compare from. Since mimikatz is the canonical example of this technique we will use its path which is CEFGH.

23/ We can then use the algorithm to calculate the ED between CEFGH and the other paths. Below are the results:
ADFGH -> 2
DFGH -> 2
FGH -> 2
GH -> 3
H -> 4 ✅ 
BEFGH -> 1
EFGH -> 1
It turns out that H is the path that is the most dissimilar from CEFGH according to the ED.

24/ Conceptually, the shorter the ED the more the paths have in common, but you might notice that maybe this isn't always a fair comparison. For instance, both ADFGH & FGH have an ED of 2, but a quick glance at the graph tells us that maybe there's something more to it all.

25/ According to the literature this is a common issue. I found this paper¹ which introduces an algorithm called Contextual Normalized Edit Distance (CED) which assigns a weight to each edit operation based on the context surrounding the operation.

[1]https://ieeexplore.ieee.org/document/4498345

26/ The paper says, "a number of authors argue that in practice, having to rewrite twice on a string of length 2 is not the same as having to rewrite twice on a string of length 200." CED divides each edit operation locally by the length of the string on which it is applied.

27/ We can recalculate the similarity after implementing the CED in PowerShell:
ADFGH -> 0.4
DFGH -> 0.4
FGH -> 0.45
GH -> 0.78
H -> 1.28 ✅ 
BEFGH -> 0.2
EFGH -> 0.2

Notice that CED scored ADFGH slightly differently than FGH even though their ED was the same.

28/ After calculating each path's CED relative to CEFGH we can see that H is the most dissimilar. This means that if we were to choose only two paths to test we would choose CEFGH and H. Now what if we want to add a third? CED is for 1:1 string comparison not 1:1:1.

29/ To solve this problem, we can calculate the CED of all strings relative to CEFGH and the CED of all strings relative to H. We can then add each string's CED relative to CEFGH to it's CED relative to H and divide by two giving us an average CED score.

30/ Calculating the Average CED: (CED(CEFGH) + CED(H)) / 2
ADFGH: (0.4 + 1.28) / 2 = 0.84 ✅ 
DFGH: (0.4 + 1.08) / 2 = 0.74
FGH: (0.45 + 0.83) / 2 = 0.64
GH: (0.78 + 0.5) / 2 = 0.64
BEFGH: (0.2 + 1.28) / 2 = 0.74
EFGH: (0.2 + 1.08) / 2 = 0.64

31/ As you probably are already thinking, this calculation can be applied recursively to rank order all paths. I wrote a script called Get-LeastSimilarPath to do just that. If we had to pick only 3 of 8 possible paths, we'd choose CEFGH, H, & ADFGH to maximize our coverage.

32/ The goal of this thread was to show that the function call graph enables us to do more than simply predict functional modifications that attackers might make to avoid detection. It also allows us to intelligently select the variants that provide the most additional coverage.

33/ Okay, so I told you all of that to tell you this. When I showed this approach to @jsecurity101 he had a really cool idea. He integrated the different paths in the format of @redcanary's AtomicTestHarness project.

34/ This means the TH comes with an implementation of each path (except the syscall for now) in the Process Read function call graph. You can then pipe the output of Get-LeastSignificantPath into Invoke-ATHDumpLsass and it will auto execute the variant for the paths you select.

35/ The cool thing is that the function call graph is relatively static meaning that you can take a function call graph that I make and it will be accurate for your organization in almost all scenarios. This makes it a really good opportunity for community collaboration.

36/ If you made it this far, I've included the code for Levenshtein Distance, Contextual Normalized Edit Distance, Get-LeastSignificantPath, & Invoke-ATHDumpLsass in the gist referenced below¹. Please play around with it and any feedback is welcome!
[1]https://gist.github.com/jaredcatkinson/014fd61dab5b01abfc791923b4a6efec

You can read the unrolled version of this thread here: https://typefully.com/jaredcatkinson/AN4qxin