Authors/Presenters: Jiwon Kim, Benjamin E. Ujcich, Dave (Jing) Tian
Many thanks to USENIX for publishing their outstanding USENIX Security ’23 Presenter’s content, and the organizations strong commitment to Open Access.
Originating from the conference’s events situated at the Anaheim Marriott; and via the organizations YouTube channel.
Overview Recently, we identified several critical Pwn Request vulnerabilities within GitHub Actions used by the Rspack repository. These vulnerabilities could allow an external attacker to submit a malicious pull request, without the requirement of being a prior contributor to the repository, and compromise the following secrets: NPM Deployment Token Compromise: Exploitation of the Pwn Request […]
RBI has issued comprehensive master directions and guidelines for banks and non-banking financial corporations to identify and address operational risks and weaknesses. These guidelines are based on recommendations from working groups focused on information security, e-banking, governance, and cyber fraud. The primary motivation behind these directives is the growing need to mitigate cyber threats arising […]
Credential phishing is a type of cyberattack where attackers attempt to deceive your employees into providing their sensitive information, such as their Microsoft usernames and passwords. What is not obvious is credential phishing is the root cause of many breaches, including the recent ransomware breach at UnitedHealth subsidiary Change Healthcare. According to UnitedHealth Group CEO […]
What is Business Email Compromise? Business Email Compromise (BEC) is a sophisticated form of cybercrime where attackers use email to deceive and defraud organizations. Unlike typical phishing attacks that cast a wide net, BEC is highly targeted and often involves impersonating a trusted individual or entity to trick employees into transferring funds or divulging sensitive […]
As DDoS attackers become more sophisticated and the attack surface grows exponentially, businesses must expand beyond an ideology of prevention to include a focus on early detection and response.
We're incredibly proud to share some exciting news at Impart Security: We've achieved SOC 2 Type 2 certification! This certification represents our unwavering dedication to providing exceptional security and operational excellence in API security.
Senator Ron Wyden wants the FTC and SEC to investigate the ransomware attack on UnitedHealth's Change subsidiary to see if there was criminal negligence by the CEO or board.
Authors/Presenters:Alex Luoyuan Xiong, Binyi Chen, Zhenfei Zhang, Benedikt Bünz, Ben Fisch, Fernando Krell, Philippe Camacho
Many thanks to USENIX for publishing their outstanding USENIX Security ’23 Presenter’s content, and the organizations strong commitment to Open Access.
Originating from the conference’s events situated at the Anaheim Marriott; and via the organizations YouTube channel.
Check Point disclosed a serious vulnerability in Check Point Security Gateway devices with certain remote access software blades enabled. See how to find them.
In “Living off the Land attacks,” adversaries use USB devices to infiltrate industrial control systems. Cyberthreats from silent residency attacks put critical infrastructure facilities at risk.
This month we have something big: Our new Third Party Risk Assessment app, TPRA. And it’s now available to current customers! Observable third-party risk assessments Vendor assessments are a huge part of any GRC program, so it only makes sense to handle them in the same platform that handles your compliance, security questionnaires, and trust […]
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.
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.
Session Enumeration function call stack with our two samples included
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, 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:
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.
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)
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.
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.
Many thanks to USENIX for publishing their outstanding USENIX Security ’23 Presenter’s content, and the organizations strong commitment to Open Access.
Originating from the conference’s events situated at the Anaheim Marriott; and via the organizations YouTube channel.
Celebrate 10 years of BSides Knoxville, featuring discussions of AI in security, historical hacking, and holistic protection, fostering a dynamic cybersecurity community.
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.
This cybersecurity playbook is inspired by David Cross’s insights on how to best handle a potential incident that could have been caused by what seemed to be a suspicious email sent to a marketing team. He recently shared his recommendations on CyberOXtales Podcast, highlighting the importance of having a clear playbook for incident response, determining […]
I don’t think it’s an exaggeration to predict that artificial intelligence will affect every aspect of our society. Not by doing new things. But mostly by doing things that are already being done by humans, perfectly competently.
Replacing humans with AIs isn’t necessarily interesting. But when an AI takes over a human task, the task changes.
In particular, there are potential changes over four dimensions: Speed, scale, scope and sophistication. The problem with AIs trading stocks isn’t that they’re better than humans—it’s that they’re faster. But computers are better at chess and Go because they use more sophisticated strategies than humans. We’re worried about AI-controlled social media accounts because they operate on a superhuman scale...
Exploring Sensitive Access Control in COSO and COBIT FrameworksThe management of access to information and resources is a critical component of maintaining the security of an organization's data. The COSO and COBIT frameworks offer distinct perspectives and recommendations for effectively establishing and managing access control measures within an organization's information security […]
In recent years, containers have become a staple in modern IT infrastructures. They provide extreme flexibility and efficiency in deploying applications. Yet, as containerization has grown in popularity, so has the need to secure these environmеnts. Container security is defined as protecting against threats and ensuring compliance with safety standards in containerized envirоnments. It has […]
Software product development initiatives are not an easy feat especially when 80% of the projects fail for one reason or another. Executing software development is...Read More
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 […]
Reading Time: 4min Scammers impersonate universities in phishing emails. Learn 5 red flags to identify fake university emails and avoid giving away personal information.
In today’s data-driven world, protecting personal information is of greater significance. The International Organisation for Standardisation (ISO) has developed ISO 27701, a comprehensive Privacy Information Management System (PIMS) standard aimed at improving privacy management within organizations. This blog will look at the specifics of ISO 27701 PIMS, its significance, and how it may help organizations […]
Threat Overview – DarkGate Malware DarkGate malware variant was first observed in the wild in 2018 (seemingly in production since 2017), evolving into a more dangerous and widespread version of itself in recent years – more notably after the takedown of the Qbot infrastructure, there has been a surge in cases involving the variant. DarkGate […]
Organizations have moved to multi-cloud environments to achieve the benefits of business resilience, agility, best-of-breed capabilities, compliance, and cost containment, or due to the result of a merger or acquisition. But distributed environments also introduce a lot of complexity that can make it hard to realize these benefits.
Many thanks to USENIX for publishing their outstanding USENIX Security ’23 Presenter’s content, and the organizations strong commitment to Open Access.
Originating from the conference’s events situated at the Anaheim Marriott; and via the organizations YouTube channel.
It all started when Open AI’s CEO Sam Altman unveiled a new ChatGPT version that included a new voice assistant seemingly inspired by the movie Her. Altman had professed his love for the movie before, declaring it his favorite. Controversy started bubbling over how Scarlett Johansson’s AI assistant character influenced ChatGPT’s real-life AI voice assistant.
As the threat landscape continues to grow, with new breaches being announced every day, Imperva continues to stay one step ahead of attackers. HTTP/2 exploits seem to be growing every quarter as more attackers use this vulnerability in new ways. We previously wrote about how Imperva protected its customers from the first HTTP/2 vulnerability, ‘Rapid […]
How old are your Kubernetes nodes? Most often, people don’t know the answer to this question, or if they do, they know that “most” of their nodes are a certain age, and some are newer. Knowing the age of your nodes is important, particularly in terms of maintaining a healthy and efficient cluster. In fact, the age of your nodes can impact your cluster’s performance, security, and stability. Let’s look at some of the primary reasons it’s important to both know the age of your nodes and keep them up to date.
Hear from Fred Burton, Ontic’s Executive Director of Protective Intelligence and former special agent, on his experience with aircraft disaster investigations. The May 19, 2024 crash of a Bell helicopter carrying Iranian President Ebrahim Raisi and Foreign Minister Amir Abdollahian appears to have been a tragic accident. When the crash occurred, Raisi was returning to…
The National Security Agency (NSA) is providing guidance on deploying a comprehensive zero-trust framework that focuses on the application and workload pillar of the Zero Trust Maturity Model introduced by the Cybersecurity and Infrastructure Security Agency.
What we know so far: A Ticketmaster AWS instance was penetrated by unknown perpetrators; “ShinyHunters” is selling stolen data on their behalf. Don’t forget to add the hidden 5% fee to the ransom.
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?
Authors/Presenters: Matteo Campanelli, Mathias Hall-Andersen, Simon Holmgaard Kamp
Many thanks to USENIX for publishing their outstanding USENIX Security ’23 Presenter’s content, and the organizations strong commitment to Open Access.
Originating from the conference’s events situated at the Anaheim Marriott; and via the organizations YouTube channel.
The group behind the RedTail malware is exploiting a new vulnerability in Palo Alto Network's PAN-OS software to run a sophisticated cryptomining campaign that is likely backed by North Korea.
The National Institute of Standards and Technology (NIST) has laid out the Cybersecurity Framework as a set of guidelines that offers outcomes that organizations can use in their cybersecurity efforts. The NIST categories include identify, protect, detect, respond, and recover. Pondurance, a managed detection and response services provider with a 24/7 security operations center, aligns its service lines with...
Travel accounts are attractive targets for fraudsters. Once access is gained, they can easily book vacations, transfer points, or sell accounts on the dark web.
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.
Strata’s Maverics Identity Orchestration Platform recognized as Best Authentication and Identity Solution BOULDER, Colo., May 30, 2024 — Strata Identity, the Identity Orchestration company, today announced its Maverics Identity Orchestration Platform received the prestigious 2024 Fortress Cybersecurity Award in the Authentication and Identity category. Strata’s Maverics implements an abstraction layer that bridges siloed and incompatible...
Login
