The 500kg Microlino is part of a new set challenging the ever-increasing domination of huge cars

Driving through central London in a tiny Microlino electric car, barely visible between the hulking SUVs, it’s surprising to be the focus of so much attention. “Yes, Lego car!” shouts a scaffolder.

Made by Micro, the family-owned Swiss company behind the mini-micro kick scooters, and modelled on the bubble cars that had a brief heyday in the 1950s, the two-seater is only 2.5 metres long – marginally smaller than a Smart car. The most unusual feature is its one and only door (there is also a rear hatch for accessing the boot), which is at the front. The windscreen and bonnet swing open to let you in.

On Detection: Tactical to Functional

Why a Single Test Case is Insufficient

Introduction

In my previous post, I explored the idea that different tools can implement the same operation chain (behavior) in various ways. I referred to these various ways as execution modalities. In that post, we explored five tools that allowed us to understand some of the most common modalities that one would expect to encounter and concluded with an image of a function call stack that represented the Session Enumeration operation with overlaid tools.

In this post, I want to explore the implications of execution modalities on detection engineering. I’m particularly interested in how diverse modalities affect our ability to evaluate detection coverage. Evaluating detection coverage is a problem we’ve seen rise to industry attention with the ATT&CK EDR Evaluations. While the objective of the evaluations is not necessarily to assess detection coverage, that is undoubtedly a question that industry consumers are interested in, and rightfully so. This post will explore why a test not specifically designed to answer coverage questions fails to provide the necessary evidence. But before we do that, let’s revisit what we learned in the previous post. This refresh will set us up for a hypothetical scenario that will allow us to understand the problems that execution modalities create for us.

NetSessionEnum Function Call Stack

In the previous post, we analyzed the netapi32!NetSessionEnum function to generate its function call stack. Based on our analysis, we know that when an application calls netapi32!NetSessionEnum, it calls the lower level srvcli!NetSessionEnum and ms-srvs!NetrSessionEnum functions behind the scenes. We then identified that we could use the “Session Enumeration” operation to group the functions.

We represent the relationship between these functions as a function call stack below:

Tool Samples

In the previous post, we analyzed five Session Enumeration tool samples; however, we will reduce our scope for this post to just two samples so we can explore how changes to the execution modality impact detectability even if the behavior remains static. I’ve selected two samples, PowerView Get-NetSession and BOF get-netsession, that overlap maximally. I selected these samples because they have the same name (Get-NetSession) and execute the same API function (netapi32!NetSessionEnum). We can, therefore, say they perform the same behavior; however, their authors implemented that behavior via different execution modalities (PowerShell Script vs. Beacon Object File [BOF]). We should expect the rule to detect both samples if we use a behavior-based approach. The problem lies in our definition of behavior-based detection, which I hope this post will help reify. Before we get going, let’s quickly review these particular samples.

Sample 1: PowerView Get-NetSession (PowerShell Script)

The first sample is the Get-NetSession function from Will Schroeder’s PowerView project. Will implemented this sample as a PowerShell script, which confers certain advantages and disadvantages to its users. When we view its source code, we quickly find that the bulk of the script’s interaction with the operating system occurs when it calls the netapi32!NetSessionEnum Windows API function.

Sample 2: get-netsession (Beacon Object File)

The second sample is a BOF called get-netsession, part of TrustedSec’s CS-Situational-Awareness-BOF project. BOFs offer a distinct advantage over PowerShell scripts because they tightly integrate with the agent. As a result, there is no need to spawn a new process, as we typically see during PowerShell execution. Since this BOF is open-source, we can review the code to understand its implementation. Very quickly, we saw a similar call to the netapi32!NetSessionEnum function, so we know that the underlying behavior of this BOF will be identical to that of the first sample we analyzed.

Integrating the Tools into the Function Call Stack

After introducing the samples and performing a quick analysis, we’ve identified that both tools call the netapi32!NetSessionEnum API function. We can now add these samples to our graphic to demonstrate where they reside in the function call stack. Notice that both tools point to the same function, netapi32!NetSessionEnum, which indicates that while the superficial details (e.g., programming language, variable names, etc.) of each tool may differ, they should be considered “functionally equivalent.” Functional equivalency is important because, given the minimal differences between the samples, we expect that a rule written to detect one sample would also detect the other. This resiliency to change differentiates between a “signature” and a “behavior-based detection.” If two tools are equivalent at the functional level, but a rule does not detect both, the rule is not behavior-based. Put another way, the rule focuses on tool-specific details rather than the tool’s behavior.

Detection Rules

Next, we will look at two detection rules. Of course, we all know that there are myriad possible detections. For instance, some rules are built using hashes, some are built using strings or other details associated with malware, and some are more focused on the behavior itself. MITRE Engenuity recently released its Summiting The Pyramid project to explore this proposition. however, for the sake of this particular exercise, we will act as if there are only two possible detection rules. We will use publicly available rules through the Sigma project for this exercise. One rule will depend on the modality, while the other will be behaviorally focused. The goal is not to say that one rule is better; instead, our goal is to understand the tradeoffs between different detection strategies. Let’s take a look at the two detection rule options.

Rule 1: Malicious PowerView PowerShell Commandlets

Rule 1, written by Bhabesh Raj, was written to leverage a potent telemetry source called PowerShell ScriptBlock Logging. If you aren’t familiar with ScriptBlock Logging, I recommend the original PowerShell ❤ the Blue Team article, which describes what it is and how it works. If we look at line 28 of the rule, which is shared below, we see that the rule is also predicated on explicitly including a specific string (Get-NetSession) in the PowerShell ScriptBlock Log. I’ve included a version of the rule below for your review:

https://medium.com/media/fcd09de414418c3a3da2542220fc7044/href

It is helpful to explicitly lay out the conditions a sample must meet for this rule to fire. I’ve listed the alert conditions for Rule 1 below:

1️⃣: PowerShell ScriptBlock Logging (SBL) is enabled

logsource:
    product: windows
    category: ps_script
    definition: 'Requirements: Script Block Logging must be enabled'

2️⃣: The tool is implemented in PowerShell (and therefore triggers SBL)

logsource:
    product: windows
    category: ps_script
    definition: 'Requirements: Script Block Logging must be enabled'

3️⃣: The Get-NetSession string is included in the script

detection:
    selection:
        ScriptBlockText|contains:
            - 'Get-NetSession'
    condition: selection

This rule is great for detecting the default implementation of PowerView’s Get-NetSession function because it is named “Get-NetSession” and, therefore, will appear in the ScriptBlock when executed. However, the rule assumes that the attacker will not alter the function’s name AND that the attacker will execute this behavior via a PowerShell script.

Rule 2: SharpHound Recon Sessions

This second rule, by Sagie Dulce and Dekel Paz, actually undersells its capability. It is titled “SharpHound Recon Sessions,” but is generic enough to cover all implementations, so long as they call the NetrSessionEnum RPC Procedure (which, as discussed earlier in this post, is true of all our samples). The rule depends on the Zero Network’s RPC Firewall project to function. It then looks for any process attempting to call the NetrSessionEnum RPC procedure, which the protocol defines as Opnum 12 of the 4b324fc8–1670–01d3–1278–5a47bf6ee188 interface.

https://medium.com/media/cc6a5aa601cf83b64df766b2dc7e3f36/href

The following conditions must be met for this rule to trigger an alert:

1️⃣: RPC Firewall is installed on all relevant processes

logsource:
    product: rpc_firewall
    category: application
    definition: 'Requirements: install and apply the RPC Firewall to all processes with "audit:true action:block uuid:4b324fc8-1670-01d3-1278-5a47bf6ee188 opnum:12'

2️⃣: The RPC Procedure is implemented by the MS-SRVS RPC Interface (4b324fc8–1670–01d3–1278–5a47bf6ee188)

InterfaceUuid: 4b324fc8-1670-01d3-1278-5a47bf6ee188

3️⃣: The RPC Procedure is NetrSessionEnum (OpNum 12)

OpNum: 12

Here, we see that the rule focuses on the execution of a specific RPC procedure, NetrSessionEnum. It may be difficult to immediately understand the viability of such a rule, especially if you are unfamiliar with RPC and its integration into standard Windows API functions. We can refer to the Session Enumeration function call stack, where we see the ms-srvs!NetrSessionEnum RPC procedure sits at the bottom of the stack. Its position indicates that all code paths will eventually result in a call to the procedure, which is good news for defenders who choose this rule.

Rule Analysis

I want to analyze both samples quickly in the context of each rule. The goal is to identify whether the sample(s) meet the conditions of each rule, as described in the previous section. Remember that the sample must meet ALL conditions for the rule to produce an alert.

Note: Both rules rely on telemetry, which may not be enabled by default in your environment. However, for the sake of this post, we will assume that our target environment has enabled all of the necessary telemetry for both rules. This assumption means that each sample will meet Condition 1 for both rules as it evaluates the state of telemetry collection, not the sample or behavior itself.

Sample 1 + Rule 1

1️⃣: PowerShell ScriptBlock Logging (SBL) is enabled ✅

• We have assumed that our hypothetical environment has SBL enabled. The first condition passes.

2️⃣: The tool is implemented in PowerShell (and therefore triggers SBL) ✅

• PowerView’s Get-NetSession is implemented as a PowerShell script. Therefore, it would be subject to SBL, satisfying the second condition.

3️⃣: The Get-NetSession string is included in the script that is executed ✅

• The function is named Get-NetSession, which means the string Get-NetSession would exist in the relevant logs, satisfying the third condition.

Overall Result ✅

• Based on our analysis of the conditions of Rule 1 and the features of Sample 1, I found that Sample 1 WOULD (✅) trigger Rule 1 to produce an alert.

Sample 2 + Rule 1

1️⃣: PowerShell ScriptBlock Logging (SBL) is enabled ✅

• We have assumed that our hypothetical environment has SBL enabled. The first condition passes.

2️⃣: The tool is implemented in PowerShell (and therefore triggers SBL) ⛔️

• TrustedSec’s get-netsession is implemented as a BOF and, therefore, would not be subject to SBL, failing to satisfy the second condition.

3️⃣: The Get-NetSession string is included in the script that is executed ✅

• The BOF’s name is get-netsession; therefore, assuming the string comparison is case-agnostic, the third condition would be satisfied.

Overall Result ⛔️

• Based on our analysis of Rule 1’s conditions and Sample 2’s features, Sample 2 WOULD NOT (⛔️) trigger Rule 1 to produce an alert.

Sample 1 + Rule 2

1️⃣: RPC Firewall is installed on all relevant processes ✅

• We have assumed that the RPC Firewall is installed in the hypothetical environment, satisfying the first condition.

2️⃣: The RPC Procedure is implemented by the MS-SRVS RPC Interface ✅

• The same RPC call specifies OpNum 12, which corresponds with the NetrSessionEnum procedure and satisfies the third condition.

3️⃣: The RPC Procedure is NetSessionEnum ✅

• The same RPC call specifies OpNum 12 which corresponds with the NetrSessionEnum procedure, satisfying the third condition.

Overall Result ✅

• Based on our analysis of the conditions of Rule 2 and the features of Sample 1, I found that Sample 1 WOULD (✅) trigger Rule 2 to produce an alert.

Sample 2 + Rule 2 ✅

1️⃣: RPC Firewall is installed on all relevant processes ✅

• We have assumed that the RPC Firewall is installed in the hypothetical environment, satisfying the first condition.

2️⃣: The RPC Procedure is implemented by the MS-SRVS RPC Interface ✅

• TrustedSec’s get-netsession calls netapi32!NetSessionEnum. According to the function call stack, this function leads to an RPC call to the MS-SRVS Interface, satisfying the second condition.

3️⃣: The RPC Procedure is NetrSessionEnum ✅

• The same RPC call specifies OpNum 12, which corresponds with the NetrSessionEnum procedure and satisfies the third condition.

Overall Result ✅

• Based on our analysis of the conditions of Rule 2 and the features of Sample 2, I found that Sample 2 WOULD (✅) trigger Rule 2 to produce an alert.

Integrating Rules into the Function Call Stack

Now that we understand both rules, we can integrate them into our graph. Remember that both Sample 1 (PowerView’s Get-NetSession) and Sample 2 (BOF get-netsession) call the netapi32!NetSessionEnum function; in other words, the samples are “functionally equivalent.” When two samples are functionally equivalent, we can attribute any difference in detection results to differences in modality or some other tool-specific detail or toolmark.

Recall that Rule 1 is based on PowerShell ScriptBlock Logging, so its detection scope will be limited to implementations that rely on the PowerShell engine. This reliance means it is married to the PowerShell Script modality discussed in the previous post. Our analysis shows that Sample 1 is implemented in PowerShell, but Sample 2 is implemented as a BOF instead of in PowerShell. Therefore, Rule 1 detects Sample 1 but not Sample 2.

Rule 2, on the other hand, is focused on the execution of the ms-srvs!NetrSessionEnum RPC procedure. Based on our understanding of the function call stack, we know that when a sample calls the netapi32!NetSessionEnum function, as both samples do, it will eventually reach the bottom of the function call stack and call ms-srvs!NetrSessionEnum. As a result, both samples will ultimately execute the ms-srvs!NetrSessionEnum procedure and thus trigger the alert. We can confidently say that Rule 1 is focused on modality (PowerShell Script), while Rule 2 focuses on behavior (Session Enumeration).

It is also worth noting that in RPC-based function call stacks, the RPC procedure sits at the base of the stack and, therefore, represents the optimal location for telemetry. Client-side telemetry implementations risk missing direct RPC implementations, like impacket, while server-side implementations lose important client-side context.

I have added both rules to the function call stack in the image below. Notice that Rule 1 is associated with a specific sample or, more generically, with the PowerShell Script execution modality. In contrast, Rule 2 sits at the base of the function call stack (at the RPC procedure). This position in the stack indicates that Rule 2 offers a more holistic approach to detecting this behavior.

Detection Analytic Categories

When we complete this analysis, we find that at least three categories of detection analytics exist.

The first, “tool-based” detections (signatures), is a well-known approach that represents a relatively solved problem. We are all familiar with different ways to build detection rules that focus on the specific details or toolmarks of known malware samples or attacker tools.

With the rise of Endpoint Detection and Response (EDR) products, we saw an effort to move beyond tool-based detections to a new approach that can better deal with the uncertainty that we face. This new category was commonly referred to as “behavior-based” detection. Behavioral detections purported to focus on what the sample does instead of what it is. Unfortunately, the term “behavior” has been poorly defined traditionally within the industry, but in this blog series, I argue that behavior should be considered identical to the operation chain. Therefore, behavioral detections for a tool like PowerView’s Get-NetSession should focus on the Session Enumeration operation.

A problem that I often wrestled with was that detection rules would present themselves as behavior-based because they had moved beyond hashes and static strings, but they didn’t make it to focus on the behavior. This disconnect was evident, especially when Red Teamers migrated from PowerShell tools to C#. It didn’t make sense to me that one could change the programming language used to write malware, which was sufficient to bypass behavior-based detections. The introduction of execution modalities as a concept helps to bridge the gap. A third detection category, which I call “modality-based” detection, seems to exist.

Many modern detection analytics fall into this third modality-based detection category. This focus on modality-based detection strategies can largely be attributed to the poor definition of “behavior” and our lack of resolution, which did not allow us to differentiate between the execution modality and the behavior. I hope this post helps detection engineers make deliberate decisions between modal and behavior detections.

Determining Which Category a Rule Belongs To

The best way to determine which category a detection rule fits into is to execute multiple test cases using samples that emphasize each category. For example, if one were to execute two PowerShell scripts that both call netapi32!NetSessionEnum, but maybe the name of the function was changed, and perhaps some comments with the author’s name were removed, and the detection rule fires for one sample but not the other, so it is likely that the rule is tool-based. If, however, a rule detects both PowerShell scripts but does not detect a BOF that also calls netapi32!NetSessionEnum, then the detection rule is likely modality-based. Finally, suppose the detection rule detects all five tool samples from the previous post. In that case, the rule is likely sufficient for detecting any variation of the behavior and would fit in the behavior-based category.

Understanding that most rules do not fit nicely into one category is essential. Instead, we find that the rule’s logic often involves elements of each approach but is predominantly aligned to one approach. For example, Rule 1, “Malicious PowerView PowerShell Commandlets”, is modality-based due to its reliance on PowerShell ScriptBlock Logging and tool-based due to its use of the string Get-NetSession. Meanwhile, Rule 2 is a pure behavior-based rule due to its location at the bottom of the function call stack.

Modality-based vs. Behavior-based Detection Approaches

An interesting dichotomy exists between modality-based and behavior-based, which makes it difficult to determine whether one approach is “better” than the other. It is possible for a modality-based approach to make executing ANY behavior challenging using that particular modality. For instance, one could imagine a detection engineer or product that learns how to spot proxied RPC. If that were the case, then it would be possible for that solution to eliminate the ability of attackers to execute any behavior via that modality. The downside, of course, is that it would be possible for attackers to execute each behavior using a different modality. It is unclear whether it is possible to eliminate all execution modalities despite the likelihood of fewer modalities than behaviors.

Similarly, we can easily imagine a scenario where a behavior-based approach eliminates a specific behavior regardless of the selected modality. We expect this from a behavior-based detection rule targeting the Session Enumeration operation. In practice, we expect to see some combination of detection approaches, primarily when multiple products exist in many environments.

Example: Detecting the Direct Syscall Modality

Gijs Hollestelle at FalconForce provides an excellent example of modality-based detection in this blog post. Gijs describes his approach to detect direct syscalls (an execution modality) where one looks for syscalls where the calling module is not ntdll.dll, win32u.dll, or wow64win.dll. The thing to notice here is that this detection strategy does not focus on a single behavior, like Session Enumeration, but instead on detecting the use of direct syscalls. This focus makes it a modality-based detection. Again, modality-based detection strategies are fine. The important thing is that we understand the strengths and limitations of whichever strategy we choose to implement.

Why a Single Test Case is Not Enough

I opened the post by explaining that execution modalities complicate our ability to evaluate detection coverage. This problem arises due to the diversity of forms of any given behavior. In his recent post, Luke Paine describes the mathematical underpinnings of detection coverage. He focused on explaining how we can calculate the coverage of a Technique based on the results of its Procedures (operation chains or behaviors). We realized that while this is correct, determining the results of a procedure is a complex problem. As I’ve described, attackers can use numerous execution modalities to implement a procedure, and each modality adds its own wrinkle. This post focuses on the problem of whether it is possible to detect any single variation using many analytics. These analytics range from specific (brittle) to generic (robust) concerning the procedure. It is not always possible to determine where a particular solution exists on the spectrum, especially when evaluating proprietary analytics. You can only build confidence in your procedure coverage when you test the same procedure via many different modalities (built-in tool, PowerShell script, Beacon Object File, Direct RPC).

Your confidence should roughly follow the same function that Luke described for the procedure to technique coverage estimate with the exception that the first test is as good as meaningless because even if you successfully detect it, you have no way of knowing whether your analytic is more like Rule 1 or Rule 2 (as described in this post). Robust detections are resilient to change. This resilience, first and foremost, should be true regarding execution modality. Still, it also should include changes at any level of resolution that is more fine grain than the functional level.

Scenario

Imagine that you are conducting a Red Team assessment. You gain initial access as an unprivileged user and are interested in determining your next step. One common approach is to pursue “user hunting,” where the attacker identifies an interesting target account (e.g., SQL Administrators), typically due to the account’s access to resources germane to the Red Team’s objectives. Once that target user is selected, the attacker must determine where the user account is logged in in the network. The red teamer may enumerate network sessions to glean this information, but they have a choice. They can use PowerView’s Get-NetSession PowerShell function or the get-netsession BOF from TrustedSec’s SA repository.

Note: In real life, there are more than two implementation options. Constraining the possibilities makes the point easier to demonstrate.

The red teamer is a PowerShell fanatic and, as a result, chooses PowerView’s Get-NetSession. Now imagine that later that day, in an exchange with the client, the red teamer is informed that their Session Enumeration was detected. The question is, “What broader assertions can we make as a result of this detection?” Here’s the rub. Remember our two detection rules? Like our two tool implementations, these represent only two of the many ways that either of the tools could be detected. However, I selected these two rules on purpose. Rule 1 only works to detect Sample 1, but Rule 2 works to detect both.

When it comes to dynamic testing, especially in cases where proprietary analytics are in play, we do not necessarily know how the analytic works under the hood. We are using our test cases as a means to reverse engineer or glean the alerting conditions of the analytic itself. When we run a test, the binary result abstracts details of how the analytic works. The test case is either detected (i.e., the rule produces an alert) or not detected (i.e., the rule does not produce an alert). Therefore, when we run our PowerView Get-NetSession test case, if the detection rule generates an alert, we often have no way of knowing whether the first rule caught it (explicitly focused on the tool itself) or the second rule (focused on the underlying behavior and therefore tool agnostic). The best or most efficient way of ascertaining is to use multiple test cases. In a sense, we would then be “triangulating” the analytics logic.

Triangulation

The process of triangulation would look like this. The first test case would be something like executing PowerView’s Get-NetSession function. Assuming it is detected, we now have two example analytics that could be responsible for the alert. We should then select a second test case to eliminate any residual uncertainty (concerning how the analytic works), so we might choose to execute TrustedSec’s get-netsession BOF. The BOF code is almost identical to the Get-NetSession PowerShell function. The difference is that the BOF is written in C and integrates directly into Beacon, eliminating the relevance of PowerShell-specific data sources such as ScriptBlock Logging. In the case of a different result, the similarity between the test cases allows us to pinpoint the cause. If the second test case is not detected, we can infer that a holistic detection rule, like Rule 2, is not in play, and the likelihood that the active rule is similar to Rule 1 increases tremendously.

One final observation is that our ability to triangulate coverage depends on the results from a single detection rule. During this type of testing, the null hypothesis is that all detection rules are tool-based until proven otherwise. If, for instance, we detected both PowerView’s Get-NetSession and the get-netsession BOF, but we depended on different rules to do so, we must assume those rules are tool-based and do not generalize to other implementations. We can, of course, continue testing to determine whether that is, in fact, the truth, but we must operate from the tool-based starting point as it is the most likely result.

Conclusion

In these two posts (Parts 12 and 13), we’ve explored how a behavior implementation matters as much as the behavior itself. We discovered that in the transition from tool-based to behavior-based detections we made an unintended discovery of modality-based detections. These detections complement a behavior-based strategy because they can detect unknown or unaccounted-for behaviors. We identified that it is impossible to evaluate detection coverage using a single test case. This fact makes red team exercises non-ideal for this particular task (although they are quite valuable for other pursuits). Purple team exercises fill this gap because they primarily implement a different testing protocol. One that focuses on presenting multiple test cases. However, the devil is in the details. Consumers should be mindful of understanding the vendor’s testing protocol including how many test cases they will execute per behavior, how those test cases are selected, and whether the selected test cases represent the range of behavioral and modal variability.

On Detection: Tactical to Functional Series

• Understanding the Function Call Graph
• Part 1: Discovering API Function Usage through Source Code Review
• Part 2: Operations
• Part 3: Expanding the Function Call Graph
• Part 4: Compound Functions
• Part 5: Expanding the Operational Graph
• Part 6: What is a Procedure?
• Part 7: Synonyms
• Part 8: Tool Graph
• Part 9: Perception vs. Conception
• Part 10: Implicit Process Create
• Part 11: Functional Composition
• Part 12: Behavior vs. Execution Modality

Part 13 was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Part 13 appeared first on Security Boulevard.

Insight #1

Transparency isn't just about promising action, it's about proving it. It means sharing the data and results that show you're following through on your commitments.

The post Cybersecurity Insights with Contrast CISO David Lindner | 5/31/24 appeared first on Security Boulevard.

As per recent reports a new social engineering attack attributed to the North Korea-linked Kimsuky hacking group is targeting human rights activists using fake Facebook accounts. This tactic, involving fictitious identities, marks a significant shift from their typical email-based spear-phishing strategies. According to a report by South Korean cybersecurity firm Genians, the attackers pose as […]

The post Alert: Kimsuky Hacking Group Targets Human Rights Activists appeared first on TuxCare.

The post Alert: Kimsuky Hacking Group Targets Human Rights Activists appeared first on Security Boulevard.

Increasing our understanding of EDR capabilities in the face of impossible odds.

Introduction

I recently had a discussion with our chief strategist, Jared Atkinson, about purple teaming. We believe that large quantities of procedures per technique affect the overall success of the assessment. I began to theorize how I could prove this concept. In this post, I will discuss the validation of my theory.

You know what assumptions do…

When you take a technique and make a broad statement of detection you are often ignoring orders of magnitude more detail, forcing those who view it to make a broad assumption about what is and is not detected. Take this hypothetical EDR marketing:

While some portions of this example are purely satirical, this still seems great! We have four different techniques that are detected! But is this the full story? If you have been following Jared Atkinson’s posts, you may realize that each of these techniques look something like this:

This is a set of operation chains for different procedures of process injection. If you are unfamiliar with what operation chains are, I recommend reading Jared’s blog series on Tactical to Functional. Using this information, I asked myself, “How could I build a representation of my understanding of the EDR’s capabilities with respect to process injection?

EDR capabilities can, and should, be measured as a set of data. Our industry has different methods of measuring capabilities and representing the resulting data. Common examples that are used for measurement include Mitre ATT&CK Evaluations, or generically mapping the Mitre ATT&CK framework to testing performed via something like Atomic Red Team. The problem with evaluations of this type are that they typically focus on one variation of a technique, which can only represent one procedure. While usually not explicitly stated, those using those projects often mistake the results for full “coverage” of that technique. The reality is that none of these approaches are designed to be used or interpreted in this fashion.

The argument I am going to make throughout this post is that these tests are not particularly sufficient to guarantee coverage. In fact, no amount of testing will ever guarantee 100% coverage of any given technique. This does not mean all hope is lost of detecting the use of process injection, but it does mean that we need to better understand what our testing results actually mean — so at least we have knowledge of the potential gaps prior to accepting the risk.

EXCELerating Capability Testing

To start proving my argument, let’s start in Excel. We will build a table that represents a set of process injection procedures that an EDR may detect. The columns will represent the individual procedures while the rows will represent each possible combination of procedures an EDR may detect. We will treat a 0 as “not detected” and a 1 as “detected”. For this first example I will limit the procedures to “Standard” (e.g., shellcode injection) and “Thread Hijacking.” I am going to say, for the sake of argument, that these are the only two known forms of process injection. This means that there are four possibilities for an EDR’s capability to detect process injection. At this point, without running any tests, an end user of an EDR will have no idea which of the four outcomes is true for their EDR.

We can safely rule out some of these outcomes because we assume that an EDR is detecting at least one of these procedures to make the claim that it detects process injection. Let’s say that the most likely candidate for detection is standard shellcode injection since that is the canonical form that comes to mind when process injection is mentioned.

If we know that standard injection is detected with our theoretical EDR, then we now have two potential cases, albeit in our hypothetical world where there are only two known forms of process injection. We can show this on the chart by graying out the rows that are not relevant to our EDR.

The chart shows that by either testing or seeing real-world examples of an EDR detecting a given procedure we removed 50% of the possible combinations of process injection procedures the EDR can potentially detect.

I want to be clear here — this is not a probability that an EDR will detect a given technique, or a full coverage of the EDR capabilities. This is merely filling in 50% of our understanding of an EDR’s capability regarding a specific technique using known procedures for that technique. I am going to continue stressing this throughout this post. All of these statistics are applicable to better understanding an EDR but none of the table entries are weighted to convey the prevalence or any other attribute of a procedure.

Let’s add a third procedure and see what happens to our potential capability.

We are dealing with exponential math here. There are two states that our data can be in, 0 or 1. So the number of potential combinations of procedures from the table that an EDR can detect is n^x , where “n” is the number of potential results and “x” is the number of procedures. So the table above can be represented as 2³or 8.

With 3 process injection procedures, we have expanded our hypothetical world to 8 possibilities, so what happens if I again run a test to see if my EDR detects standard shellcode injection?

We have once again eliminated 50% of the possibilities of what our EDR detects, with a single test case, even though we have doubled the amount of potential possibilities. What happens if you run a second test, and see if your EDR detects thread hijacking?

It does detect it! This allows us to throw away all of the potential states where thread hijacking is 0. Another 50% of the remaining possibilities have been removed. Are you starting to see the pattern? For each test case we ran we could remove 50% of the remaining possibilities from the table.

Let’s try one more test and bump this up to 6 total forms of process injection. Following our previous formula, our potential set of detection possibilities should be 2⁶ or 64.

Awesome! As before, I want to test my EDR and see if it is capable of detecting standard shellcode injection. We already know that it does from our previous testing but will it really remove 50% of our detection possibilities? Before immediately showing you the answer, look at the first column of binary data.

The options for Standard Shellcode Injection alternate between 0 and 1 every single time. So if we do detect it, then it will absolutely remove 50% of our results; just as it did before with a different number of process injection procedures. You may recognize these tables as truth tables and our testing process as being similar to a binary search algorithm, allowing each of our tests to reduce our possible detection combinations by half. This is demonstrated again in the following graphic by running each test in succession for the six chosen procedures shown before, and taking it to the logical conclusion.

This simply validates our previous testing with a larger dataset; There has been a singular theme throughout these tests. Each time we had limited our table of process injection procedures to a specific number of remaining rows. Given enough testing, it’s possible to arrive at a single combination of procedures an EDR will detect for a given technique, but what happens when we don’t know how many procedures there are?

To Infinity and Beyond!

Excel works well to illustrate finite numbers of procedures for performing a technique, but it fails to work as well when we don’t know what the true number of procedures are. The reality is that even though I listed six different forms of process injection for this post, there are certainly more than that in existence. In fact, as far as I know, there are an infinite number of ways to perform process injection!

The easiest way to visually represent this is with a curve.

Note: I am not good at math. The curve and the resulting formula is not an attempt to provide a real or usable method for plotting capability, it is simply an illustrative tool. Shoutout to Evan McBroom for helping me find a curve that fit what I was trying to show.

Take the following curve for example:

y=10/2^{x}

In this example the curve starts with Y=10 for X=0 and Y will decrease by 50% every time X increases by 1. The area under the curve represents the potential combinations of procedures an EDR may detect for a given technique, with the upper bound of X being the number of process injection procedures tested. It may appear at a glance that running 10 test cases is all that is needed to completely fill in our understanding of the EDR, but if you take a closer look you will see that the curve never actually reaches the X axis.

This is illustrating that the area underneath the line is actually infinite because the potential number of procedures for performing process injection is infinite and thus our possible combinations for which of those procedures an EDR may detect is also infinite.. In reality, there certainly is a limit to the different ways process injection may be performed, but for the purposes of testing and measuring, we will likely never know what that limit is.

All of that aside, knowing the infinite possible number, the reality is that the real number of total procedures for performing process injection are probably much lower than that. If we run a single test on a single procedure, we can plot our knowledge gained on the curve.

What about if we run 7 tests on 7 different procedures?

In regards to a specific technique, we can be significantly more certain now about what procedures our EDR can, and cannot, detect.

I want to stress again that this doesn’t show an increase in detection coverage of process injection for the EDR itself — that’s not what we are testing. This is an increase in your knowledge of the EDR’s capability surrounding process injection.

I understand that this post ignores any kind of weighting for each of the procedures. As an example, it may be more likely that you see standard shellcode injection than APC injection. I understand that, but since I am not tracking a desired state of coverage for each procedure, it’s not strictly relevant to the current discussion.

(Lack of) Information Warfare

Recently, I have been reading “The User Illusion” by Tor Nørretranders. In Chapter 2, titled “Throwing Away Information,” he shares an example of information loss in the context of grocery shopping.

When you go to the grocery and fill up a cart full of food, you check out, and they hand you a receipt for $218.52 — that receipt carries with it the full list of items you used to reach that total. Three months later, you check your credit card statement and you see a charge at Walmart for $218.52. If I asked you to go back to Walmart, armed with only that information, and recreate your exact cart of groceries, could you do it?

I would venture to guess that you couldn’t. There are far too many possibilities in Walmart that add up to $218.52 — as Tor says in the book:

But in fact there is far less information in the result than in the problem: After all, there are lots of different combinations of goods that can lead to the same total price. But that does not mean you can guess what is in each basket if you know only the price.

— The User Illusion, Tor Nørretranders

We make these kinds of generalizations on a day-to-day basis, but often without realizing or caring about the information we are leaving behind. Tor uses the example of temperature to convey this. When someone asks what the temperature is outside, and you respond with 75 degrees, you ignore the immeasurable number of potential states of matter and molecules required to place the temperature at 75 degrees. In this case, you don’t really care, you just want to know if you should wear a jacket or not — the information conveyed was sufficient, and the discarded information was not relevant. Even if you wanted to know, there is no way to reverse engineer the exact state from the resulting temperature.

How is this relevant to our EDR and purple team? Similar to the charge on your credit card, if an EDR makes a claim to “detect” process injection, then there are upwards of sixty-four different combinations of “detection” (based just on the six procedures I used earlier for illustration) that can lead the vendor to make that claim. Luckily, we can use something like a purple team assessment to successfully reverse engineer a representative set of results that could have led the vendor to make that statement.

The truth is that the vendor has already done this as well. The likelihood that they released a product incapable of detecting some form of process injection, and yet claim to do so, is quite low; however, most, if not all, vendors are not forthcoming in giving you the “receipt” of their testing. They may point to something like the aforementioned Mitre ATT&CK Evaluations as a facsimile for a true receipt, but the detail and depth of that testing I would argue is insufficient for assessing the true capability of an EDR, and as a result, your ability to secure your enterprise with it.

Conclusion

If you think back to our original pretend EDR marketing graphic, knowing what we know now, perhaps it should look more like this:

Now we know what set of possible data lies behind the shiny marketing and catchy buzzwords — but the only way to get to that data is to test different procedures, and as many of them as possible (within reason).

The question is, would you rather make the assumption, or know the reality?

Thanks:

• Jared Atkinson
• Evan McBroom
• Joshua Prager

To Infinity and Beyond! was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post To Infinity and Beyond! appeared first on Security Boulevard.

One of your greatest information security risks is likely your employees. Data from Verizon's 2024 Data Breach Investigations Report (DBIR) indicates that 76% of breaches involved the human element, and 68% of which were the result of human error.

The post Can File Integrity Monitoring Catch Internal Threats? appeared first on Security Boulevard.

Sudden cut in pollution in 2020 meant less shade from sun and was ‘substantial’ factor in record surface temperatures in 2023, study finds

The slashing of pollution from shipping in 2020 led to a big “termination shock” that is estimated have pushed the rate of global heating to double the long-term average, according to research.

Until 2020, global shipping used dirty, high-sulphur fuels that produced air pollution. The pollution particles blocked sunlight and helped form more clouds, thereby curbing global heating. But new regulations at the start of 2020 slashed the sulphur content of fuels by more than 80%.

The FCA is considering opening a compensation scheme for customers after an influx of complaints

When Gary Hill took out a £12,500 loan to pay for a new family vehicle in late 2014, he had no idea that the north London dealership he had travelled to from his home in Bedfordshire could have sway over his monthly payments.

But the 45-year-old was in a bind, having started a new job that no longer gave him access to a company car. Hill agreed to pay £335 a month over more than five years to take home a Nissan Qashqai, piling costs on to a household budget already supporting three children and the up-keep of his family home.

The funding cutbacks announced in February have continued to hobble NIST’s ability to keep the government’s National Vulnerabilities Database (NVD) up to date, with one cybersecurity company finding that more than 93% of the flaws added have not been analyzed or enhanced, a problem that will make organizations less safe. “With the recent slowdown of..

The post NIST Struggles with NVD Backlog as 93% of Flaws Remain Unanalyzed appeared first on Security Boulevard.

People who fall for the scheme are told to pay the shipping fee before the piano is sent. If they do, that's the last they hear from the bad actors.

The post Scammers Build Fraud Campaigns Around Free Piano Offers appeared first on Security Boulevard.

Source: securityboulevard.com – Author: Steve Winterfeld Security experts have many fun arguments about our field. For example, while I believe War Games is the best hacker movie, opinions vary based on age and generation. Other never-ending debates include what the best hack is, the best operating system (though this is more of a religious debate), […]

La entrada Using Scary but Fun Stories to Aid Cybersecurity Training – Source: securityboulevard.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.

Parliamentary staffer may have played ‘significant role’ in alleged payments to MEPs to promote propaganda on Voice of Europe website

Belgian police have searched the European parliament office and Brussels home of a parliamentary staffer who is believed to have played “a significant role” in a Russian interference operation, the national prosecutor has said.

French authorities also carried out a search of the employee’s European parliament office in Strasbourg at the request of the Belgian examining magistrate overseeing the inquiry into corruption and Russian interference.

Need to get your audience’s attention so they listen to your cybersecurity lessons? Share these true stories to engage their attention and, perhaps, make them laugh.

The post Using Scary but Fun Stories to Aid Cybersecurity Training appeared first on Security Boulevard.

OpenAI has a new Safety and Security Committee in place fewer than two weeks after disbanding its “superalignment” team, a year-old unit that was tasked with focusing on the long-term effects of AI.

The post OpenAI Launches Security Committee Amid Ongoing Criticism appeared first on Security Boulevard.

Scammers impersonating Microsoft, Publishers Clearing House, Amazon and Apple are at the top of the FTC’s “who’s who” list. Based on consumer reports and complaints to the agency, hundreds of millions of dollars were stolen by bad actors pretending to be brands.

The post ‘Microsoft’ Scammers Steal the Most, the FTC Says appeared first on Security Boulevard.

As threats increase in sophistication—in many cases powered by GenAI itself—GenAI will play a growing role in combatting them.

The post The Rise of Generative AI is Transforming Threat Intelligence – Five Trends to Watch appeared first on Security Boulevard.

Source: securityboulevard.com – Author: Wajahat Raja Recent reports claim that the Microsoft Threat Intelligence team stated that a cybercriminal group, identified as Storm-1811, has been exploiting Microsoft’s Quick Assist tool in a series of social engineering attacks. This group is known for deploying the Black Basta ransomware attack. On May 15, 2024, Microsoft released details […]

La entrada Black Basta Ransomware Attack: Microsoft Quick Assist Flaw – Source: securityboulevard.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.

Recent reports claim that the Microsoft Threat Intelligence team stated that a cybercriminal group, identified as Storm-1811, has been exploiting Microsoft’s Quick Assist tool in a series of social engineering attacks. This group is known for deploying the Black Basta ransomware attack. On May 15, 2024, Microsoft released details about how this financially motivated group […]

The post Black Basta Ransomware Attack: Microsoft Quick Assist Flaw appeared first on TuxCare.

The post Black Basta Ransomware Attack: Microsoft Quick Assist Flaw appeared first on Security Boulevard.

Analysis of real-world data suggests annual cost of fuelling PHEVs is nearly double manufacturers’ claims

Drivers of bestselling plug-in hybrid cars pay £500 a year more on fuel for their cars than manufacturers’ figures suggest, according to analysis of real-world data, largely because owners tend to charge them less frequently than expected.

Laboratory tests of plug-in hybrid electric vehicles (PHEVs) suggest that fuel should cost £560 a year, but real-life data suggests the cost is nearly double that, at £1,059 a year, according to analysis by the Energy and Climate Intelligence Unit (ECIU), a climate research group.

Possible Defense Against Ongoing Remote Monitoring Campaign

• Organizations not using SuperOps RMM should verify the absence of network activity associated with the domain names: [.]superops[.]com, [.]superops[.]ai.
• Improve employee cyber hygiene.
• Use and constantly update anti-virus software.
• Regularly update operating systems and software.
• Use strong passwords and change them regularly.
• Back up important data.

Ukrainian Financial Institutions Also on Smokeloader’s Radar

It was hit by an uninsured driver after they bought it to accommodate a wheelchair for my disabled mother

My parents’ car was hit by an uninsured driver. They were taken to hospital but suffered no serious injuries. The repair was being organised by their insurer, Saga, but four months later they are still waiting for the return of their damaged vehicle. This is causing significant hardship since my mother is disabled and the car, a Volkswagen T-Roc, was recently purchased to accommodate her specialist wheelchair.

Saga initially insisted they were only entitled to a compact courtesy car because it had erroneously recorded that my father was at fault for the accident. I complained to Saga’s head office but received no reply. Four days after the collision, Saga told my father that its chosen garage had refused the repair job, and that he should find another garage. My sister rang the garage in question, which claimed it had not turned down the job, and that it was waiting for the car to be brought in.

A new Sawday’s guide to dog-friendly days out selects ideal beaches for dog walkers year-round – plus places to stay nearby

Dog-friendly year-round but with an on-leads rule between 1 April and 31 August to protect ground-nesting birds, Holkham beach is a brilliant family destination. The walk down to the golden sand is enchanting – along boardwalks and through pine forest – and there’s a cafe serving homemade sandwiches and cakes. Lots of great local walks too.
Stay pet-friendly Sueda Cottage, with its own walled garden, is a minute’s walk from the harbour and pub. From £89 a night (sleeps 4, plus two dogs)

Petrolheads are quick to scorn the idea of electric car racing, but the series’ chief executive is sure that time, technology – and even geography – are on his side

Jeff Dodds has been a fan of Formula One “all my life”, he says. That is probably a good thing because, as chief executive of electric racing series Formula E, he must find the comparison with its fossil-fuelled cousin is constant.

So he takes it head-on. Such is the growth and improvement in technology in Formula E that one day, he says, it is “realistic that a question will be asked about whether both can exist together”. Talking to the Observer in the race company’s west London headquarters, he adds that maybe one day, as Formula E develops, “they won’t [both exist]”.

David Scattergood on how the work of independent fostering agencies is offering a glimmer of hope and Peter RC Williams on the government’s obligations. Plus a letter from Nina Lopez and Tracey Norton

George Monbiot is right to highlight the state of the free market in children’s social care (How can a child in care cost £281,000 a year? Ask the wealth funds that have councils over a barrel, 18 May). With more children in care now than ever before, children’s residential and foster care provision is a lucrative cash cow for hedge funds and asset management companies, using taxpayers’ money to profiteer from the lives of children in care.

However, there is a glimmer of hope. A small number of independent fostering agencies are charities, providing services on a not-for-profit basis. Working alongside local authorities, with no shareholders to enrich, not‑for-profit fostering agencies reinvest surplus funds back into their organisation to fund activities, educational support, and therapeutic interventions for their children. They also fund training and financial support for their foster carers, and activities such as holidays for children with disabilities and additional needs. This model should be the rule, rather than the exception for the whole sector.

Inglorious Basta(rds): 16 days on, huge hospital system continues to be paralyzed by ransomware—and patient safety is at risk.

The post Black Basta Ascension Attack Redux — can Patients Die of Ransomware? appeared first on Security Boulevard.

Source: www.techrepublic.com – Author: Cedric Pernet A new report from IBM X-Force exposes changes in the Grandoreiro malware landscape. The banking trojan is now capable of targeting more than 1,500 global banks in more than 60 countries, and it has been updated with new features. Also, Grandoreiro’s targeting has become wider, as it initially only […]

La entrada IBM X-Force Report: Grandoreiro Malware Targets More Than 1,500 Banks in 60 Countries – Source: www.techrepublic.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.

Privacy FAIL: Apple location service returns far more data than it should, to people who have no business knowing it, without your permission.

The post Apple API Allows Wi-Fi AP Location Tracking appeared first on Security Boulevard.

Source: www.darkreading.com – Author: Karl Mattson 5 Min Read Source: vska via Alamy Stock Vector COMMENTARY As our world becomes increasingly digitized, malicious actors have more opportunities to carry out attacks. Data breaches and ransomware are on the rise, and the urgency to fortify our digital defenses has never been greater. With one cyberattack occurring […]

La entrada Preparing Your Organization for Upcoming Cybersecurity Deadlines – Source: www.darkreading.com se publicó primero en CISO2CISO.COM & CYBER SECURITY GROUP.

Cybercrime Gets Easier

“The crime as a service dark web is very affordable. The only way to combat AI-based attacks is to harness the power of AI in our cybersecurity strategies.”

“Outcomes like these are necessary to stop threat actors before they can encrypt systems or steal sensitive information, and none of this would be possible without AI,” Sikorski added.

Election Security and Disinformation Loom Large

“Our country is one of the only ones in the western world that doesn't have a digital identity strategy,” Amlani said.

Safe AI Use Guidelines Proposed by Public Policy Advocate

“Principles for responsible use of AI technologies should be applied broadly across development and deployment,” Laperruque said.

1. Built upon proper training data
2. Subject to independent testing and high performance standards
3. Deployed only within the bounds of the technology’s designed function
4. Used exclusively by trained staff and corroborated by human review
5. Subject to internal governance mechanisms that define and promote responsible use
6. Bound by safeguards to protect human rights and constitutional values
7. Regulated by institutional mechanisms for ensuring transparency and oversight

Deepfake Zoom of Doom: Construction giant Arup Group revealed as victim of January theft—10% of net profit lost.

The post CFO Deepfake Redux — Arup Lost $26M via Video appeared first on Security Boulevard.

Today, organizations rely heavily on servers to manage their operations efficiently. Ensuring optimal server performance has become crucial for maintainingRead More

The post Key Server Monitoring Metrics for Measuring Performance appeared first on Kaseya.

The post Key Server Monitoring Metrics for Measuring Performance appeared first on Security Boulevard.

Insurer Allianz says scam by criminals on motorbikes and scooters increased by 6,000% last year

Motorists have been warned to be vigilant after a 60-fold increase in “crash for cash” fraud claims involving motorbike and scooter riders staging accidents so they can blame innocent drivers.

The insurer Allianz said its data showed that claims relating to this scam increased by 6,000% between January and December 2023 – a significant jump from the 50% increase the year before.

Reverse-engineering tools, rising jailbreaking activities, and the surging use of AI and ML to enhance malware development were among the worrying trends in a recent report.

AI and ML are making life easier for developers. They’re also making life easier for threat actors.

The post Hackers Leverage AI as Application Security Threats Mount appeared first on Security Boulevard.

This is not a blog about the recent upheaval in the magical realm of SIEM. We have a perfectly good podcast / video about it (complete with hi-la-ri-ous XDR jokes, both human and AI created).

This is about something that bothered me for a long time (since my Gartner days) and I finally figured out how to solve this complicated problem.

Of course, the answer is … A TWITTER POLL!

(source)

On a more serious note, pay attention to the wording “if you look at your SIEM, how many detections have you written.” By combining my Twitter and LinkedIn poll data (that displayed a similar trend), I have arrived at ~800 votes here, that tell a story…

.. so what is the story?

My hypothesis that this data reveals the existence of two worlds

On the left, we have “detection as code” , on the right, we have “EDR-ization of SIEM.” On the left, we fix FPs, on the right, we whine about the FPs to the vendor. On the left, we study threats and make detections. On the right, we pay…

Initially, I wanted to say that these are warring clans, but I think a better metaphor is parallel universes: Clan 1 (who engineer their detections) counts about 30% of the security population and most of their detection content is written by them. Clan 2 (who largely consume detections) is a bit larger at 35% and most of their detection rules are written by their vendors, consultants or whoever else and perhaps lightly tuned. What about the remaining 35%? I intuit that they are in transit to one of the parallel universes…

P.S. What does it has to do with decoupled SIEM? Well, I think the clan of detection engineers strongly prefers the decoupled SIEM, while their opposites skew “tightly integrated” SIEM…. So there is that.

P.P.S My muse for this post is incomparable Allie Mellen :-) You rock!

Resources:

• Detection as Code? No, Detection as COOKING!
• EP117 Can a Small Team Adopt an Engineering-Centric Approach to Cybersecurity?
• Cloud Security Podcast on the Day of 3 SIEM Transition
• Cooking Intelligent Detections from Threat Intelligence (Part 6)
• Decoupled SIEM: Brilliant or Stupid?

Back to Cooking: Detection Engineer vs Detection Consumer, Again? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Back to Cooking: Detection Engineer vs Detection Consumer, Again? appeared first on Security Boulevard.

Electric and hybrid vehicles are quieter than cars with combustion engines, making them harder to hear, especially in urban areas

Hybrid and electric cars are more likely to strike pedestrians than petrol or diesel vehicles, particularly in towns and cities, according to an analysis of British road traffic accidents.

Data from 32bn miles of battery-powered car travel and 3tn miles of petrol and diesel car trips showed that mile-for-mile electric and hybrid cars were twice as likely to hit pedestrians than fossil fuel-powered cars, and three times more likely to do so in urban areas.

Enlarge / "Look, everybody! It's the one thing that ties the whole story together! And it's pointing us toward this legacy dungeon, inside which must surely lie safety and salvation. Let us go forth." (credit: FromSoftware/Bandai Namco)

There are lots of ways to enjoy Elden Ring, beyond the core attack/dodge/survive gameplay. You can obsess over builds, appreciate the mastery of speedrunners and grand masters like Let Me Solo Her, or mix and match the huge variety of armor in pursuit of Fashion Souls. And then there is lore. There is so much of it, and most of it has the consistency of campfire smoke.

Elden Ring tells its backstory (written in part by George R.R. Martin) primarily through item descriptions and environmental hints. The scraps of narrative that do exist stand unsteadily against unreliable narrators, contradictions, cut content, and lovably enthusiastic fans who take small hints to their illogical extremes. Developer FromSoftware and primary creator Hidetaka Miyazaki do almost nothing to disprove misunderstandings or reward accurate conclusions, although they appreciate the energy. Miyazaki will just casually tell IGN that there's a "small element" that hasn't been discovered, offer nothing more on that, and leave fans like me craven with an unmet need for conclusion.

Elden Ring: Shadow of the Erdtree story trailer.

I love this and cherish the way FromSoftware will never in my lifetime confirm my hopes or expectations. So with the surprise arrival of an honest-to-goodness story-based trailer for the Shadow of the Erdtree expansion, due out June 21, I was given yet another feast of vague notions and evocative images.

Read 11 remaining paragraphs | Comments

On Detection: Tactical to Functional

Part 12

Introduction

At Shmoocon 2015, Will Schroeder (Harmj0y) gave a talk titled “I Hunt Sys Admins,” describing how attackers can hunt (or find the location of) system administrators throughout the network. The talk is only 15 minutes long, so I highly recommend you watch it to understand the motivations and implementations of attackers concerning “user hunting.” As you can see in the screenshot below, Harmj0y describes the motivation behind this attack as “determining where high-value users are logged in” to steal their credentials. At the time of his talk, Mimikatz was the primary method of stealing credentials; still, user hunting continues to be necessary for identity snowball attacks regardless of the credential access technique used.

Later, “user hunting” became the foundation of the popular attack path mapping project BloodHound. Initially, BloodHound would provide a map of the environment by understanding how users, computers, groups, logon sessions, and other factors impact access control. Specifically, users’ location within the network is a crucial component because the location is both ephemeral and admin access to a machine implies the ability to take over the identity of any users logged on to that system. If an attacker can find where high value users are located in the network, they can steal their credentials. As described in his talk, account takeover is not limited to Mimikatz. Attackers can take over accounts via many techniques within the Credential Access Tactic category, such as LSASS Credential Dumping, Token Impersonation (not sure why this is not considered a Credential Access Technique), etc.

In his March 2018 blog post, Rohan Vazarkar (CptJesus) wrote about some of the mechanisms SharpHound uses, the data collection component of the BloodHound project, to collect the necessary data for projecting attack paths. In the Session Collection section of the post, he describes how attackers use the NetSessionEnum function to collect this information. In this post, we will analyze the NetSessionEnum function, understand the operation chain associated with the user hunting technique, and examine five tools that implement this behavior. Ultimately, we will explore how changes to how a behavior is executed (execution modality) can impact detection as much as the operation chain (behavior) itself.

NetSessionEnum

In their descriptions of User Hunting, Harmj0y and Rohan mentioned one Windows API function that was particularly interesting: NetSessionEnum. As a part of the Win32 API, you can find the NetSessionEnum documented online. Below is an image of the function’s overview, which describes it as “[it] provides information about sessions established on a server.” It also shows the syntax for how developers can call the function from their application. In his post, Rohan details how SharpHound calls this function and why specific parameters must be specified in certain ways to guarantee the function returns the information necessary for mapping attack paths.

In one of my previous blog posts, “Understanding the Function Call Stack,” I described how the Windows API is an abstraction that sits atop the functionality. Eventually, this post will require a clear understanding of the NetSessionEnum function call stack, so we should check it out now.

This section will walk through the NetSessionEnum implementation to demonstrate how the function call stack was derived. Feel free to skip to the Behavior section if you trust me. :)

Finding the Implementing Library

The first step is identifying which dynamic link library (DLL) implements the NetSessionEnum function. The Requirements section of the Microsoft API documentation page provides information about Netapi32.dll, the DLL in the screenshot below.

So when Harmj0y and CptJesus, or frankly most other developers, mention NetSessionEnum, they specifically mean the version of that function implemented within netapi32.dll or written differently netapi32!NetSessionEnum.

The netapi32!NetSessionEnum syntax is a common way to differentiate between functions with the same name implemented in different DLLs. This additional precision provides clarity in discussions when the difference between, say, kernel32!OpenProcess and kernelbase!OpenProcess might matter. The way to interpret it is DLL!Function, where DLL corresponds to the implementing DLL and Function refers to the function name. We will see later in the post that it is necessary to be specific about the function we refer to.

While it is true that the majority of legitimate applications will use this “orthodox” version of the API, we’ve seen a trend among malware to use lower-level undocumented API functions or system calls (syscalls). With that in mind, it is worth understanding the entire function call stack to understand what exactly happens after netapi32!NetSessionEnum is called. To figure this out, we can open netapi32.dll in a disassembler like IDA Pro.

netapi32!NetSessionEnum

After loading netapi32.dll into our disassembler, we find that the netapi32!NetSessionEnum function is implemented as a “forwarded export” to srvcli.dll.

This means that when an application calls netapi32!NetSessionEnum the call is transparently forwarded to srvcli!NetSessionEnum, so in order to continue our exploration of the function call stack we will need to load srvcli.dll into our disassembler next.

srvcli!NetSessionEnum

Upon decompiling srvcli!NetSessionEnum, we immediately see a call to the NdrClientCall3 function, which is responsible for facilitating RPC procedure calls. This particular instance calls the NetrSessionEnum (Opnum 12) procedure implemented by the [MS-SRVS] Interface (otherwise known as the Server Service Remote Protocol).

For a detailed description of how to analyze calls to the NdrClientCall3 function, I highly recommend checking out Kai Huang’s Uncovering RPC Servers through Windows API Analysis post. Search for the section titled “A sneak peek into SspiCli!SspipLogonUser and NdrClientCall3,” where he explains how to break down this function’s different parameters and related structures.

Using this analysis, we can construct a function call stack that demonstrates the relationship between the three functions (netapi32!NetSessionEnum, srvcli!NetSessionEnum, and ms-srvs!NetrSessionEnum) that our samples called. The nested nature of this relationship allows us to treat all three functions as “functionally equivalent,” meaning that we can ignore the differences between tools implementing one instead of the other since they are minimal.

As a result of this analysis, we have a new function call stack starting with netapi32!NetSessionEnum, flowing through srvcli!NetSessionEnum, and finally, calling the NetrSessionEnum RPC Procedure implemented by MS-SRVS (ms-srvs!NetrSessionEnum). This function call stack implements the Session Enumeration operation as shown below:

Note: I’ve found that the NdrClientCallX functions are best represented as the RPC Procedure that it is executing. In this case, I’ve used ms-srvs!NetrSessionEnum in its place.

In previous examples, we’ve seen that the function call stack ends at the syscall because it represents the transfer of execution from user mode to kernel mode. For this model, we treat what happens in the kernel as a black box because developers cannot simply call functions that reside in the kernel in the same way they call lower-level API functions like those that reside in ntdll.dll. This same concept is applied to RPC procedures because they transfer execution from the RPC client (in this case, srvcli.dll) to the RPC server (srvsvc.dll). Generally speaking, especially regarding user hunting, the use case for Session Enumeration is to do so remotely. As such, the server component can be treated as a black box because it is not possible, as far as I know, for the client to call the same functions as the server component on a remote system.

Behavior

At this point, we are familiar with the concept of user hunting and its application for red teamers and threat actors. We’ve also become familiar with the Session Enumeration operation that facilitates this behavior. If you’ve reached this point in the series, you may wonder why I’m only talking about a single operation. After all, I thought procedures were chains of operations? Well, in this case, NetSessionEnum is a function that has no dependency on other functions. As a result, Session Enumeration can manifest as a stand-alone operation in a chain, as shown below:

Session Enumeration’s stand-alone nature lends itself as a great teaching aid. Since there is only one operation, we can skip any questions regarding which operation is optimal for detecting the procedure. After all, we should be able to figure this out since there is only one option. I think of this much like the approach to teaching mathematics. In algebra class, students learn how to solve single-variate equations (solve for X) before they learn to tackle multivariate equations (solve for X and Y). The authors of the algebra curriculum understand that many of the real-world applications of mathematics are multivariate; however, they also understand that if you cannot solve for X, you likely cannot solve for both X and Y! In our case, a single-operation procedure is equivalent to solving for X. It only gets more difficult as you add more operations to your chain or multiple chains to your detection.

The critical takeaway is understanding that the operation chain represents the behavior we discuss when we say “behavior-based detection.” In this case, the behavior is a single operation. Still, in other cases, the behavior may be a sequence of operations in a chain, as we’ve seen with LSASS Memory Dumping or Process Injection (shown below for reference):

Execution Modalities

At this point, we’ve identified the behavior (i.e., operation chain) that attackers want to execute as part of user hunting. Still, the attacker must weaponize the behavior before they can use it in their operation. Behaviors are conceptual; tools are concrete. Developers implement these ideas in code, which makes them concrete and usable. During this weaponization process, developers have many implementation options. Despite the relative simplicity of this user hunting procedure, there is a relatively wide range of ways to implement the behavior. This section will analyze five tools that implement “user hunting” (the Session Enumeration operation), but each does so uniquely. The fact that developers can implement the same behavior in many ways brings up a distinction I believe is essential for detection engineers to understand. The differences between behavior and weaponization. I describe these differences as “execution modalities.”

Example: Heart Rate Monitoring

An example that I like to use to differentiate behavior from modality is heart rate (HR) monitoring. In today’s society, it is common to encounter several devices that monitor our HR for one reason or another. How often do we stop and think about how this diagnostic is measured? It turns out there are three primary diagnostic modalities used to measure heart rate.

Digital

The first mode is the most rudimentary but readily available to all of us. It is an old-fashioned pulse measurement. The measurer takes the pulse by pressing their fingers against an artery of the patient. Generally, the pulse is taken on the wrist (radial pulse) or the neck (carotid pulse). Luke Paine told me EMTs humorously call this a “digital” measurement.

Optical

Photoplethysmography (PPG) is the second modality. We typically encounter this modality in consumer electronic devices such as Apple Watches and Oura Rings, as well as the pulse oximeter that hospitals use. This mode uses an LED to illuminate the skin so an optical sensor can measure blood flow changes, which the device interprets as heart rate. Due to the optical sensor, we call this modality “optical.”

Electrical

The third mode, electrocardiography (ECG/EKG), uses electrodes attached to the skin in different locations to measure the electrical changes caused by each cardiac cycle. We will call this modality “electrical.”

Each approach has its pros and cons but measures the same phenomenon. Numerous considerations, such as necessary precision, activity levels, equipment availability, etc., influence the practitioner’s modality choice. This section will show how to apply the same conceptual approach to attacker tradecraft. However, detection engineers must differentiate between the behavior and the modality used to implement said behavior. We currently conflate these two concepts, leading to numerous detection efficacy mistakes.

Session Enumeration Tools

Now that we’ve established the difference between behavior and modality, I want to look at tools that implement the same behavior but use different modalities. In this section, we will analyze five tools that implement the Session Enumeration operation and thus can be used for user hunting, as Harmj0y described in his talk. Some tools are built into the operating system, some are meant to be administrative tools, and some were constructed explicitly for attackers. Interestingly, while they all ostensibly do the same thing, they are weaponized differently. These differences in weaponization affect execution, detectability, extensibility, interoperability, etc. An important point is that our high-order objective in detection is behavior-based, not modality-based. Therefore, we should be interested in detecting Session Enumeration (behavior-focused), not Session Enumeration in PowerShell (modality-focused). I labeled each tool’s subsection using the tool name [function] (modality) syntax to simplify things. Let’s jump in!

net.exe session [srvcli!NetSessionEnum] (Built-in Console Application)

It is natural to start our analysis with a tool built into the Windows operating system: net.exe. Many of you are familiar with net.exe and its many modules. For instance, you may have used net user /add to add a local user account to a computer. However, one module, net session, allows for the enumeration of user sessions, making it relevant to our analysis.

We can learn how this tool works by opening it in our disassembler. Once our disassembler has loaded and analyzed it, we see that when a user executes net.exe, it calls the CreateProcessW API function to create a new process called net1.exe.

For those unfamiliar, there is a fun story about the creation of net1.exe involving Y2K.

After we open net1.exe, we find a subroutine called session_display that eventually calls the NetSessionEnum function. A glance at the imports table shows that net1.exe calls srvcli!NetSessionEnum. Calling the function in srvcli.dll is interesting because it skips a level in our function call graph (netapi32!NetSessionEnum). However, it is essential to note that the first parameter, servername, which represents the computer on which the function will enumerate sessions, is set to 0. The documentation indicates that when the servername parameter is NULL, shown as 0, it will enumerate sessions on the local computer. Since the NULL value is hardcoded, net(1).exe is not a tool that can facilitate “user hunting.”

NetSess.exe [netapi32!NetSessionEnum] (Third-party Console Application)

The second tool is a third-party binary released by Joeware called NetSess.exe. This tool has been around for a long time and is often referred to by later implementations.

Like net.exe, I threw NetSess.exe into a disassembler to peek under the hood. I eventually found a call to NetSessionEnum, which is the basis of the tool’s functionality. The difference is that NetSess.exe calls the netapi32 version of the function and takes the servername parameter from the command-line. User control of the servername parameter means the tool facilitates the enumeration of sessions on remote systems, meaning that NetSess.exe is the first tool we can use for user hunting!

One drawback to NetSess.exe, however, is that it is a console application. As a result, an attacker must bring this tool with them or download it to the target system before using it. As we progress through our tour of user hunting tools, we will encounter other tool variations that do not require dropping a binary file to disk. This in-memory execution is, of course, valuable to an attacker to avoid standard disk-based AV scanning.

PowerView Get-NetSession [netapi32!NetSessionEnum] (PowerShell)

Our third tool is Harmj0y’s PowerView Get-NetSession function. PowerView was the precursor to BloodHound as we know it. Will wrote the original BloodHound collector as a wrapper around various PowerView functions, including Get-NetSession. As the screenshot below shows, Get-NetSession relies on a call to netapi32!NetSessionEnum. Like NetSess.exe, Get-NetSession can enumerate sessions on remote computers, which means it supports “user hunting.”

When Harmj0y wrote PowerView, PowerShell’s value proposition was that it could execute scripts in memory (without being dropped to disk and thus subject to AV scans). Also, PowerView targeted PowerShell version 2, which did not include many security features we’ve all come to know and love. These features made PowerShell an exciting modality for user hunting and attacker tradecraft in general.

get-netsession [netapi32!NetSessionEnum] (BOF)

TrustedSec provides a Beacon Object File (BOF) called get-netsession as part of their CS-Situational-Awareness-BOF project. I imagine this BOF’s name is a tribute to the PowerView function discussed earlier, but I have not confirmed this. Since we can access the get-netsession source, we can review the code to understand its implementation. Very quickly, we see a call to the netapi32!NetSessionEnum function, so we know that its behavior will be similar to the previous tools we’ve analyzed.

An advantage of BOFs is that they integrate the functionality directly into the agent itself, removing many more superficial detection opportunities. For instance, when executed, it does not create a process (like NetSess.exe or powershell.exe). Detections focused on process names, command-lines, PowerShell ScriptBlocks, etc., will not be relevant for this modality.

netview.py [ms-srvs!NetrSessionEnum] (Direct RPC Request)

The final tool we will analyze is part of the popular Impacket suite. For those unfamiliar with Impacket, it is a Python framework primarily intended for working with network protocols (e.g., RPC). While the framework supports interaction with many RPC Interfaces, it also includes a set of example scripts to demonstrate its functionality. One such example is netview.py, which we will analyze.

netview.py seems to be a reimplementation of Rob Fuller’s netview.exe, which Harmj0y discussed in his Shmoocon talk. The original tool did much more than simple Session Enumeration; we see the same in Impacket’s implementation. However, we can focus on the Session Enumeration component of the script, shown below in the getSessions function. Here, we see a call to the srvs.hNetrSessionEnum function, Impacket’s implementation of the [MS-SRVS] NetrSessionEnum RPC procedure (ms-srvs!NetrSessionEnum).

According to the NetSessionEnum function call stack we built earlier, the netapi32!NetSessionEnum function eventually calls the ms-srvs!NetrSessionEnum RPC procedure as part of its execution. Additionally, our analysis of the function call stack showed that nothing happens between netapi32!NetSessionEnum and ms-srvs!NetrSessionEnum, so any application that calls the RPC procedure directly, like Impacket, will not skip any observable behavior. However, it tremendously reduces the observable footprint of execution due to a modal change.

An exciting feature Impacket facilitates is the ability to proxy these requests to the target. Proxying allows the implementation of the behavior without the need to run an application on target or call the relevant Win32 API Function (e.g., netapi32!NetSessionEnum). This approach challenges many assumptions in contemporary detection engineering strategies, such as the Implicit Process Create.

Result

When the analytical dust settles, plotting the samples we analyzed on the function call stack is useful. In doing so, we find three samples (NetSess.exe, PowerView Get-NetSession, and BOF get-netsession) called the high-level netapi32!NetSessionEnum function, one sample (net session) called the undocumented srvcli!NetSessionEnum function, and one sample (Impacket netview.py) called the ms-srvs!NetrSessionEnum RPC procedure directly. The updated graph is below:

Detection engineers, malware analysts, and thread intel analysts must learn to differentiate between behavioral and modal changes. Behavioral changes result in a new or different operation chain. Modal changes focus on how an operation is executed, not how it is changed. Generally speaking, a behavioral change is more substantial than a modal change. Modern endpoint detection and response (EDR) sensors generate events that focus on operations. As a result, changes that do not affect the operation chain (the behavior) should not generally impact behavioral detections. It is, however, critical to consider whether your detection rule is resilient to modal changes. If not, it likely falls in the “signature” category. There’s nothing wrong with using signatures as a part of a comprehensive detection strategy, but we often conflate signatures with behavioral detections.

Modality Masquerading as a Technique

Another thing I want to point out is what I perceive to be an error in the way that ATT&CK categorizes some techniques. All tools analyzed in this post implement T1033 System Owner/User Discovery. We know the behavior because we can observe the operation chain (in this case, just a single operation) they are executing. However, for PowerView’s Get-NetSession, an additional technique also applies, specifically T1059.001 Command and Scripting Interpreter: PowerShell. PowerShell is not a technique; instead, it is an execution modality. The distinction between technique (behavior) and modality is important because a modality, like PowerShell, can be applied to any technique. It also applies to some of the other Command and Scripting Interpreter sub-techniques. For instance, Windows Command Shell. Does NetSess.exe implement T11059.003 Command and Scripting Interpreter Windows Command Shell? I guess so, but that is the least exciting aspect of that sample.

I’m not trying to say that you shouldn’t detect abnormal PowerShell command-lines and ScriptBlock executions like encoded commands and Unmanaged PowerShell. What I’m saying is that this technique is disproportionately common because it is not a behavior like most of the other techniques. It is an execution modality that attackers can apply to most techniques. The problem is that this causes detection rules that over indexes on the PowerShell aspect of, for instance, PowerView’s Get-NetSession function, to miss all of the other equally devastating implementations out there.

Conclusion

Threat actors and red teamers are spoilt for choice while pursuing their objectives. These choices are not limited to which technique they will use to steal credentials or laterally move, but they also include which tool they will use to implement that technique. Depending on their modality, these tools afford the attacker different capabilities. As defenders, we must understand these differences and their implications towards our ability to detect and defend against them.

During our analysis, we saw one tool that is built into the operating system (Built-in Console Application), a tool that had to be dropped to disk (Third-party Console Application), a tool that could run in PowerShell’s memory (PowerShell Script), a tool that runs in the memory of an arbitrary process (Beacon Object File), and a tool that can run via a proxy without ever touching the subject endpoint (Direct RPC Request). It is self-evident that if we want to detect user hunting or Session Enumeration more specifically, we must detect all implementations regardless of their modality.

The truth is that most of us only detect some of the five. We may detect PowerView’s Get-NetSession because we are skeptical of PowerShell code. We may detect net.exe (even though this is not particularly threatening) because it is built-in and has predictable command-line arguments. Do we detect the BOF or the Impacket variation? How about some variation that only calls netapi32!NetSessionEnum, but we have no other known indicators? Have you tested it? In a later post, we will continue building on this knowledge to demonstrate why a single test case does not provide sufficient evidence to answer these questions confidently.

On Detection: Tactical to Functional Series

• Understanding the Function Call Graph
• Part 1: Discovering API Function Usage through Source Code Review
• Part 2: Operations
• Part 3: Expanding the Function Call Graph
• Part 4: Compound Functions
• Part 5: Expanding the Operational Graph
• Part 6: What is a Procedure?
• Part 7: Synonyms
• Part 8: Tool Graph
• Part 9: Perception vs. Conception
• Part 10: Implicit Process Create
• Part 11: Functional Composition

Behavior vs. Execution Modality was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Behavior vs. Execution Modality appeared first on Security Boulevard.

It takes most organizations six months or longer to detect and contain a data breach. Early detection is critical to ensuring an incident doesn't become a full-scale breach. Real-time monitoring is essential for the "rapid detection and response" necessary for both regulatory compliance and adequate protection.

The post Identifying Suspicious Network Changes: 8 Red Flags to Watch For appeared first on Security Boulevard.

Monitoring user activity on your critical endpoints is a vital part of an effective cybersecurity strategy. Organizations need to monitor both remote and local user sessions to ensure user accountability, manage cybersecurity risks, enable prompt incident response, and comply with relevant cybersecurity laws and regulations. This is a step-by-step guide on how to monitor user […]

The post How to Record SSH Sessions and Monitor User Activity in Linux with Ekran System [Hands-on Guide] appeared first on Security Boulevard.

In episode 330 Tom, Scott, and Kevin discuss the new features for iPhones and Android phones designed to warn users about secret trackers, possibly aiding in identifying stalkers. The hosts discuss Apple and Google’s collaboration on a technology called DOLT (Detecting Unwanted Location Trackers), aiming to improve user privacy by detecting Bluetooth trackers like Tiles […]

The post New Tracker Warning Features on iPhones & Androids, 2024 Verizon Data Breach Investigations Report appeared first on Shared Security Podcast.

The post New Tracker Warning Features on iPhones & Androids, 2024 Verizon Data Breach Investigations Report appeared first on Security Boulevard.

When our new motorhome broke down in France we felt unsafe and were stranded for five days

When I retired from work last year, my wife and I set off on a road trip to France in our new motorhome. Two weeks into our trip, the engine failed on a campsite. We’d bought a £284 breakdown policy with the RAC, including European cover, and a recovery vehicle arrived promptly. The mechanic was unable to fix the problem, so we were told it would be towed to a dealership. However, the recovery truck was not long enough to carry the vehicle and, after trying to manoeuvre it off the campsite, the driver left it blocking a lane. A larger truck was eventually sent and, since it was getting late, the motorhome was moved to a storage depot for the night.

The site, shared with a breaker’s yard, was unstaffed and we were advised by the driver to stay with the vehicle for security reasons. That night we witnessed people with their faces covered entering vehicles and removing their contents. It felt very menacing. The RAC was unable to find a dealership willing to take us the next day and offered us a hotel, but we feared it would be unsafe to leave the motorhome unattended in the depot, so spent another alarming night expecting to be transferred to a repair garage the next day.

The flowers are blooming and everyone’s loving the first signs of warmer weather in the garden, especially the birds and slugs

Gardening ups and downs! One warmer May morning I arrive with seeds for sowing but find something’s eaten all but one of the baby pea plants. I feel almost tearful, and fear for the survivor.

I sow more seed and scatter the soil with organic slug pellets, guilt fighting anger. The climbing French beans haven’t yet raised their heads. Does everything seem a bit slower this year? Too wet too early perhaps. Though it might more easily be my impatience.

Children crying out for stability are paying the highest price for Britain’s chaotic and exploitative residential care

I’m a patron of a small local charity that helps struggling children to rebuild trust and connection. It’s called Sirona Therapeutic Horsemanship, and it works by bringing them together with rescued horses. The horses, like many of the children, arrive traumatised, anxious and frightened. They help each other to heal. Children who have lost their trust in humans can find it in horses, which neither threaten nor judge them, then build on that relationship gradually to reconnect with people.

It’s an astonishing, inspiring thing to witness, as the children begin to calm, uncurl and find purpose and hope. It can have life-changing results. But, though I can in no way speak on Sirona’s behalf, I’m painfully aware that such charities can help only a tiny fraction of the children in desperate need of stable relationships, trust and love.

George Monbiot is a Guardian columnist