This blog is part three of our detection engineering series; which provides examples of how detection engineers can use capability abstraction and the detection spectrum to implement Detection-in-Depth. This third post will reference both part 1, Capability Abstraction and part 2, Detection Spectrum, and attempt to relate this post to the concept of the Funnel of Fidelity. When mapped to the Funnel of Fidelity, the Detection-in-Depth concept will take place at both the detection phase and partly the triage phase.
Funnel of Fidelity
Detection Engineering with Kerberoasting Blog Series:
Introduction
When developing detections based around a technique or a pattern of events, detection engineers have to consider if the highly precise analytics in place cover all of the known iterations for an attack technique. In contrast, detection engineers must also consider if there are specific events to audit which would represent choke points that the attacker must cross to complete an attack technique independent of implementation. Security organizations want to compliment precise detections with broader detections to provide a comprehensive approach to detecting an attacker technique. The precision or coverage that the analytic provides can be a useful metric for the overall comprehensiveness of an organization’s Detection in Depth.
This post will focus on detecting the attack technique, kerberoasting, in a comprehensive way, and the necessary considerations that detection engineers must determine when creating a detection of this type. Considerations such as:
- The breadth of coverage
- The expected true positive rate
- The triage context that an alert provides
These considerations can be directly associated with the time it will require an analyst to complete their analysis of the alert. Comprehensive detections incorporating both broad and precise analytic results have a dynamic impact on security operating centers (SOC) ability to timely analyze the alert.
Detection in Depth
Detection-in-Depth
The concept of Detection in Depth is the implementation of numerous detections for a single attack technique which will increase the likelihood that the attacker will trigger one or many of the detections created. Detection engineers will abstract multiple choke points that an aggressor must pass to complete the technical execution of a specific attack technique and audit those choke points at different phases of the attack.
Auditing on the choke points that an adversary technique must traverse varies at the different levels of abstraction from the technique itself. The complexity and coverage of these analytics inversely match the manageable false positive rate and the relatively low tolerance of true negative rate. Precise analytics unavoidably create blind spots that can miss simple changes to code or command line arguments. Broader analytics require higher levels of analysis and are more prone to false negatives under the stress of alert fatigue. Acting as a mesh, Detection in Depth provides comprehensive coverage by layering precise analytics and mitigating those inherited blinds spots with the layering of broader detections. When combined in a layered approach, analysis of a collection of layered alerts containing contextual information/data are triaged quickly and response time is drastically lowered. After all, if it takes 10 minutes to review an alert and 5 minutes to execute the attack technique, the adversary will have the upper hand.
Abstraction and the Spectrum
Concerning the kerberoast attack technique, we will incorporate the abstraction layers researched by Jared’s Capability Abstraction post and we will plot the practical analytics and their associated abstraction layers along the spectrum researched by the Detection Spectrum post.
Jared Atkinson’s Capability Abstraction post dives into the layers of abstraction of four kerberoast attack technique iterations, and the Detection Spectrum post discusses the spectrum of precise and wide-breadth coverage analytics. Detection engineers can utilize both of these concepts to build detections that have a flexible range across the different abstraction layers and the precise/broad spectrum. The abstracted layers of the attack technique enable us, as detection engineers, to create analytics that can leverage chokepoints aligned with a specific layer. Combining these layers with the consideration of precise and wide-breadth coverage analytics enable us to extrapolate events related to more than one iteration of the attack technique in contrast to a single precise signature detection for a specific tool.
Capability Abstraction Map of T1208 Kerberoasting
Above, the different layers of abstraction presented by Jared’s research, and with this research, the determination of where on the spectrum these abstraction layers reside. Utilizing the spectrum concept detection engineers can then identify which detections are best suited for analytic purposes and which analytics would be better suited for contextual data sources.
Detection Spectrum
Implementation Considerations
Operationalizing the Detection in Depth concept must be completed after the detection engineers have completed the abstraction map of the different attack iterations as the map will dictate the data sources required to create analytics. The layered detections of the attack technique will very often leverage multiple data sources, and this can be utilized to the defender’s advantage.
Internal-specific audit configurations should be considered, as a data source may need to be enabled before a mesh of analytics can be utilized to holistically cover a specific attack technique. With the example of Kerberoasting, the process monitoring data source would only trigger a small portion of the attack execution and would likely not provide enough context to quickly respond to such an alert. By mapping out the data sources necessary (i.e process monitoring, logon events, service account requests), detection engineers can utilize multiple data sources and create numerous complementary detections that address the attack from different perspectives.
Detection engineers will gauge which of the chokepoints identified within the abstraction map can be implemented based on their organization’s audit capabilities. Defenders cannot audit a chokepoint when the audit mechanism is extremely broad. An example of this would be to audit the service account request Windows Security Event data source instead of auditing the use of API calls utilized to request service accounts. Taking a step back to choose a different data source is sometimes necessary to achieve the goal of identifying different interactions of an attack technique execution.
Addressing Blind Spots
The hard advantage gained by layering multiple detections for a single attack technique is the defender’s ability to address shortfalls in other detection approaches. Often organizations create a singular high fidelity detection for a specific attack technique and leverage having multiple different attack technique detections along the kill-chain. From a high-level view, this method is a good starting point, but the blind spots that this method creates should be addressed via Detection in Depth.
Organizations that support the previously mentioned method severely limit their auditing capabilities to just a singular iteration of the attack technique execution. These organizations will attempt Detection in Depth at the Tactic level instead of the Technique and Sub-Technique level. An example of what this looks like: an organization implements broad detections of phishing attempts at the initial access level and the precise detection of the Mimikatz iteration of Kerberoasting via command-line arguments at the Credential Access level. Due to the lack of other detections surrounding Kerberoasting and the precision of the one Kerberoasting detection that has been implemented, the organization has created blind spots in their defensive posture. If that same organization were to have implemented multiple layers of Kerberoast detections that address the blind spots created by the precise Kerberoast detection, the likelihood of detection would increase drastically.
Funnel Mapping
During the detection phase of the Funnel of Fidelity, a mature security organization will create many analytic types to layer their approach in detecting a given adversary technique. Identifying the purpose of the analytic helps to understand the expected false positive rate and where within this layered approach the analytic should be utilized. An organization that only focuses on building many broad detections within their arsenal may miss out on the easy-wins, provided by the precise detection approach. Another consideration is that broader detections typically have a very high expected false positive rate and this false positive rate can cause alert-fatigue with an organization.
The triage phase in Funnel of Fidelity provides alert-tuning that will circle back and influence the detection phase. Often, anomaly-based analytics create the largest blockage in alert-tuning as the expected false-positive rates are derived from the contrast to the baseline. Precise analytics, signatures, and canary objects, offer the first line of defense as this detection type is what normally alerts a security organization to a breach by catching known indicators seen in previous breaches. Precise analytics do exactly what they are meant to do: alert in the area that the signature is present — to think otherwise, is irrational.
It’s worth considering, the detection phase is strongly controlled by the collection phase and can dictate which type of analytic data is available to the SOC analysts. With a limited amount of events inbound during collection, less mature security organizations may handle the precision and expected low false-positive rate of these event types with ease. In contrast, technique and wide coverage analytics may inundate analysts or be found to be unavailable.
Layered Detections
Operationalizing the Detection in Depth concept can be completed via a layered detection strategy that will utilize initial, mid, and post-attack analytics. At which phase of the attack technique execution the detections occur doesn’t concern the Detection in Depth concept as long as the blind spots of the precise analytics are covered by the broader analytics.
Initial-Attack Phase
Initial Attack Phase Showing First Forms of Detection
The initial-attack phase uses detections that audit the initial impact on the environment due to the technique execution. Most often the initial attack phase consists of the compromised source host committing the technique execution, and these detections are usually centered around binary results- the signature is present or the signature is not. These binary results are normally caused by the staging of the tool used whether in memory or via disk. At this phase of the detections, defenders will not dismiss the importance of identifying the low-hanging fruit with rapid response time. Time constraints when investigating an alert must always be at the forefront of the defender’s mind. To proactively identify the threat, defenders need to reduce the triage time of an alert to as little as possible. The process of reducing triage time can be enhanced greatly with the incorporation of signatures or “brittle” analytics. Defenders may not always catch the tool staging due to trivial evasion techniques that an adversary can utilize, but the Detection in Depth concept will catch the adversary at another chokepoint to provide coverage of the blind spots created by the detections utilized in this attack phase.
Example 1: Cryptographic Hashes
Without going into too much detail, as mentioned in the precision of cryptographic signatures of binaries and scripts during both Post 1 and Post 2, cryptographic hashes enable analysts to identify adversary staging and execution of tools (often via the organization’s Anti-Malware solution) with the highest level of accuracy. Analysts should have a great deal of trust in their Anti-Malware solutions if these security solutions are updated with the latest signatures derived from publically available intelligence.
Example 2: SOAR for Faster Response in Initial-Attack Phase
Security Automation, Orchestration, and Response (SOAR) suites offer an opportunity to automate the low-hanging-fruit detections with the fastest response time. Many organizations have moved towards leveraging SOAR to automate the signature-based alerts which enable their analysts to focus proactively on the next phase of the attack technique execution. In my own professional opinion, the vendor-provided auto-alert and response procedures must be well-documented when using SOAR, or the analysts will spend just as much time analyzing the alert and response actions taken as they would without the suite.
The hard advantage defenders gain by identifying adversaries in the initial phase of the attack technique is the extremely quick triage time from these initial-attack alerts. A more mature security operating center will have documented response procedures specifically in the case that these signature-based alerts are fired. A well-practiced response strategy that leverages the use of signature-detections often results in two analysts triaging the initial-attack alert — one of which is determining the events that unfolded in temporal proximity and the other analyst will be attempting to identify the next steps within an attack technique chain. When a mature organization responds to the initial-attack alerts in this manner, the analysts reduce the triage and response time in the same swing and the organization can move towards more proactive detections.
Mid-attack Phase
Mid-Attack Phase Identifying the Choke Points Used to Detect the Communication Between Attack Controlled Hosts and KDC
This portion of the technique execution often contains chokepoints that can be implemented to identify the use of the key characteristics of the technique and alert on multiple iterations of the attack technique executed. From an operational perspective, detection engineers want to utilize a choke point that has the lowest false-positive ratio but identifies more than one of the attack technique iterations to cover the blind spots of other detections.
Example: 1 Processes (NOT LSASS) Connecting to KDC over Port 88
Utilizing network-based analytics such as filtering for processes communicating over port 88 that are not lsass.exe offer an opportunity to identify one iteration of the kerberoasting attack technique. As stated in the Capability Abstraction post, Kerberos is a network authentication protocol and connects to the Kerberos Key Distribution Center (KDC) to authenticate the user. By monitoring for the port 88 communication and contrasting that communication against the organization’s baseline; defenders can quickly identify the Rubeus implementation of the attack technique. However, some processes do legitimately communicate with the KDC over port 88 such as Java or legacy services. Compared to other abstraction layers, the network connection analytic, in the context of detecting kerberoasting, is possibly the best analytic detection engineers can implement after some alert tuning. This analytic is very false-positive prone but leads to opportunities of correlating non-standard Kerberos traffic with a connection that is, in fact, a TGS-REQ.
Example 2: Canary Accounts (Mass TGS Requests)
The precise detections used will vary depending on the attack technique being detected, but for Kerberoasting, a canary service account with a tempting associated Service Provider Name (SPN) offers a very precise mid-attack detection. Sean Metcalf has provided details on how to configure the auditing of a canary account to detect Kerberoasting. The consideration of operationalizing canary service accounts is whether to attach real permissions and services to this service account or not; as the temptation to Kerberoast, this account will be lost if the attacker conducts recon to discover this account to be an unviable attacker vector. However, the expected false negative rate, as referenced in Detection Spectrum, should be also considered, for an attacker may target another specific service and avoid the canary service account altogether.
Any SPN can be set to a Canary Service AccountMass Kerberoast Targeting Several Service Accounts Including our Canary Service Account
Example 3: Canary Accounts (SPN Discovery)
Adversaries may attempt to enumerate the SPNs of tempting service accounts before trying to request the TGS. The SPN discovery adversary technique enables attackers to have a smaller event log footprint until the necessary TGS is requested. By setting System Access Control Lists (SACL)s on the directory object (service account), defenders can effectively audit for anytime an adversary attempts to enumerate the service account’s SPN.
SACL audit on Read All Properties for SQLService (Canary Account)Event ID: 4662 “An operation was performed on an object.” SACL Generated Event for SPN EnumerationObject Name from Previous 4662 Corresponds to ObjectGUD for SQLService (Canary Account)
Example 4: Audit All Windows Event: 4769
Layering the network connection analytic over the precise detections overcomes the latter’s blindspots. Post 2 explains the pros and cons of utilizing Windows Event ID 4679 to expose the ticket requests that an adversary would make during the attack technique execution. Auditing 4769 events would provide coverage for every known iteration of the Kerberoasting attack technique.
Targeted Kerberoasting of the Service Accounts
Layering the canary service accounts with the network-based identification of processes spoofing the use of the Kerberos port offers us several approaches to identifying kerberoasting. However, I would be remiss if I did not mention the well-known “Encryption Downgrade” detection and why I did not consider it a viable detection for the layered defenses. The “Encryption Downgrade” detection utilizes analytics to audit specifically for Windows Event ID: 4769 with an Encryption Type of RC4. (RC4 is magnitudes faster for adversaries to crack than the other mentioned encryption types). As was mentioned in Will Schroder’s webinar, the “Encryption Downgrade” detection is difficult to realistically operationalize in a normal environment due to the default backward compatibility settings implemented by Microsoft. MS-ADA2 states that the msDS-SupportedEncryptionTypes attribute is utilized by the KDC to decide on the encryption type used. By default, for Win7 and greater, and Win Server 2008 and greater, the encryption type utilized will be 0x1C which is “RC4|AES128|AES256.” However, for service tickets backed by user accounts and trusted accounts, the default is 0x7 which is RC4. What this means is: any service ticket request for a service that is backed by a user account will by default be RC4. These settings can be explicitly changed, but often normal environments have many third-party applications that will be broken if this setting is changed.
Post-Attack Phase
Comprehensive Detections Covering Kerberoasting
Continuing the effort of creating a comprehensive detection within the concept of detection-in-depth, there are a few more detections that are worth considering when attempting to detect kerberoasting. Though many organizations consider these post-attack detections as a response strategy, defenders can implement the following detections in the event that our precise and chokepoint detections have failed us. These detections provide the coverage of blind spots that detection engineers cannot mitigate in the previously mentioned layered detections.
Security organizations can gain a “home field advantage” by identifying the crackable service accounts within their environment whose passwords can be cracked in less than 10 days before a Kerberoasting attack occurs. Configuring more robust auditing for the known crackable accounts after baselining their behavior can lead to faster response times. Often the listing of such accounts is the result of a penetration test, and thus smaller organizations may not have the technical experience to determine which accounts can be cracked.
Example 1: 4624 Logon Events (Service Accounts)
The response of the comprehensive kerberoast detection can be aided with the tracking of Windows Security Event 4624, Logon Event, for only service accounts that have logged in to endpoints after the 4679 ticket requests have occurred. Detection engineers can add context to this response analytic by determining the logon type and whether or not the service account referenced in the logon event has a unique or rare relationship to the endpoint that has been logged onto. If the SPN of the service accounts do not display the exact endpoint that the service account is normally logged into, and vice versa for the endpoint name, the adversary may have to utilize blind luck to identify the exact host and bypass the logon relationship tracking. In a larger environment, behavior-based detections, such as relationship strength of users and endpoints, forces the adversary to utilize expert tradecraft to remain undetected and defeat statistical odds.
Conclusion
A comprehensive mesh of detections targeting multiple iterations of an attack technique stands to gain as much context as possible (with the current detection capability of an organization) to provide an analyst with several detailed alerts highlighting the attacker technique used. The concept of layering analytics to provide context aims to aid an analyst in making the tough decisions fast, such that they can determine if the collected events are malicious or benign. Consultants, analysts, and security practitioners each find themselves met with this exact dilemma at some point in the career. It’s at this junction that defenders hope to gain as many details about the events or storyline that has occurred. Many times the triage decision is based on organic experience biased towards the previous history of the analysts themselves, however, defenders stand to make a higher fidelity choice when they have programmatically gathered as much context related to the events that they can hope to possibly identify.
I’d like to thank my colleagues for aiding in the research of these considerations when presenting this layered approach. Many aspects of Detection in Depth are derived from conversations that I have had with SOC analysts, security researchers, and defensive experts that I have had the pleasant opportunity to meet.
Detection in Depth was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
Article Link: https://posts.specterops.io/detection-in-depth-a2392b3a7e94?source=rss----f05f8696e3cc---4