Writing detections when stuck with EDR

Introduction


Making the leap to purchasing and maintaining an EDR solution can be huge for organisations so huge in fact that they never really progress from there when it comes to visibility on assets. This is an important consideration because organisations should aim to achieve some level of detection engineering but will likely never get to explore the associated complexities. So how can organisations effectively and easily write detections that actually help to protect them when they are only able to leverage an EDR tool.

Understanding your tools limitations


To most people EDR tools are incredibly verbose in the telemetry they capture from any given asset but unfortunately relative to overall telemetry available they actually only capture what the vendors think is the most pertinent. This is for obvious reasons because ingesting telemetry at the scale vendors do comes at a significant cost so they implement "cost-saving measures" like limiting the amount of any one given telemetry source can send in a given time period or just outright ignoring some sources. These global limits need to be explored so that when you begin writing detections you have a strong understanding of what your EDR can and can't see.

This continues to the extent that at large your only ever going to see your tools interpretation of activity occurring on an asset which can vary wildly between tools and of course importantly everything you see has already happened so understanding time constraints is important too. With this in mind your likely going to be limited to building detections for atomic behaviours or procedures and not the actual code running on your systems unlike if you had the capability to deploy Yara rulesets.

These are not absolute statements and different EDR tools can and do capture some incredibly verbose sources and provide incredible context to what is actually happening like for example what permissions are assigned to a file when its executed or even raw events from etw providers (thank you MDE team) So it is incredibly important to find these features by diving into your telemetry and exploring as they are rarely documented (if you haven't already you will be pleasantly surprised by what your EDR tool can actually do). Examples below:


Carbon Black -  Process Metadata



Crowdstrike - Telemetry sources





Defender for Endpoint - Telemetry Sources 
Source: Olaf Hartong


Understanding your limitations


More than likely if you work in a security team you are swamped with work and as always you should be focusing on achieving brilliance in the basics first not the detection engineering outlined in this post. With that said if you're ready to take the plunge into just getting something started you need to take into consideration your own personal expertise and how its going to impact the shape of your detection engineering program.

If you do not feel equipped to reverse engineer payloads, perform dynamic analysis and ultimately have a strong foundational understanding of how your operating systems work then that's ok! In the immediate term it's perfectly viable to focus on using other people's work so long as you expend effort identifying the overall quality of the detection and ensuring that quality is kept when translating it to your tools and environment. 

A big part of detection engineering is the thinking that goes into the creation of detections beyond the technical work. Some key topics you will want to explore are as followed:

  • Do you have the appropriate telemetry for the detection?
  • Do you have even better telemetry than the detection intends to use?
  • Once built how is the detection meant to be responded to?
  • Does the detection need to be put in front of a human or can it be automated?
  • How are you going to test and validate that the detection is working?
  • If something changes how do you monitor how it impacts your detections fidelity?
Luckily there are lots of fantastic resources that answer these questions so do your research using resources the community has already made.

While you are going to be restricted by your limitations it's still worthwhile figuring out what you can't detect because by documenting what the detection is, why you can't detect it and what the return on investment would be you can establish a trend that will highlight key areas in your security monitoring program and posture that you can push for new additions for and at the very least it's an excellent learning exercise to explore how your systems work and what's available to you.

Designing your program

Building a program for your detections helps ensure consistency and quality. I've captured below what yours will likely look like if you are stuck with EDR and do not have a lot of time:




Your Trigger 

This component is the why and when to you perform some detection engineering. It could be just when you find something of relevance in the news, as a result of posture and asset assessments or even your own ingenuity. At this step, its important to decide how much time and effort your going to commit to the rest of the lifecycle.


Repository

Once your trigger has activated and you have gathered a detection 'idea' its a good idea to keep it in a repository, particularly because oftentimes you might not have time to complete the entire lifecycle right there and then. This repository will need to capture a few points around the idea such as the below:

  • Research Sources
  • Relevant Technologies
  • Data/Time
  • Priority
  • Detection idea
Don't be afraid to let your repository build up with lots of ideas so long as you provide the appropriate metadata so the ones you really need to establish get done when you have time. If you want to look into more mature models for repositories check Florian Roth's post here Capturing Detection Ideas to Improve Their Impact | by Florian Roth | Medium

Working Queue


Now that you have a detection idea you want to begin the necessary work to build the detection. Use the content already detailed at the top of this post to guide you on this. In particular focus on the quality of the detection, you are making.


Testing and Validation


Almost finished! with the detection, you have built make ensure you spend time and effort testing the logic your applying works with actual data in production and measuring whether when the detection raises an alert is it as expected. This can include the below items:

  • Does your detection contain actionable information?
  • Is your detection being routed via the appropriate workflow ie enrichment?
  • Is the detection as precise as you intended it to be?
  • Are you missing actual malicious activity?
  • Are the volume of alerts so great it degrades the value of the detection?

Deployment

Finally, you need to devise a method to deploy your detections. If you have only a few tools or instances to deploy to then manual efforts are worthwhile alternatively if you have a lot of places the detection needs deploying to consider automating via the APIs available in all major EDR tools. Regardless of the method make sure that when you deploy the rule you note a period of time to monitor it for immediate and obvious issues. 

What's Next?

Next, I will be covering extending your EDRs capability using third-party productions in particular THOR scanner and KAPE/.









Popular

Endpoint on Adrenaline : One

Image
Introduction   This blog series will capture how to maximise the protection of an endpoint using the various technologies in the Defender suite. The controls outlined in the series will each need to have their own considerations taken into account for a given environment but hopefully at a minimum it will be clear just how powerful of an offering Microsoft has.  Unfortunately due to the highly modular and distinct diversity in controls Microsoft offers things are often overlooked and misconfigured when tests are conducted. With this in mind, the shortest possible route to a solution for this is utilizing the recommendations, CSPM and Secure Score technology contained within Defender 365 and Defender for Cloud as it will automatically conduct posture assessments and inform you of things you have missed and may want to turn on (IE dont take these recommendations lightly) Lastly, I would recommend reading the book “Defender for Endpoint in depth” from packt as it showcases the complexitie
Read more

Brilliance in the Basics

Image
Introduction Tired of watching you and your friends get compromised, do exactly what's in this blog and start beating adversaries. Avoiding the memes adversaries win because of simple mistakes and neglect and we all already know what they are so I'm going to list them for you. Its all for free too. Enumerate To put it simply, there shouldn't be anything you don't know about your environment, you should know who all your users are, where all your electronic devices are and what they do, what applications you have and what versions they are. Enumeration is the jet fuel for making good defensive decisions. I wrote about how to enumerate your environment here  Securing your estate: The First Step (goblinloot.net) . Follow these steps and become the arbitrator of your own environment  Your perimeter is a bridge, not a wall Monitor your perimeter as best as you can but always assume it has already been defeated. Monitor endpoint system and process telemetry and southwest traf
Read more

Investigate

Image
  Introduction This document details how an analyst should conduct investigations and triage in the normal duties of their job. It will describe concepts and logic that enable analysts to look at data, ask investigative questions, evaluate those questions and arrive at assertions about what they have found. An Alert For the most part, analysts begin their investigative work when an alert is generated. Alerts are fantastic because they are a statement that something has happened and something needs to be done about it. Typically alerts are filled with information that an analyst can then use in their investigation. Alerts are generated by detections and these detections can come in many shapes and sizes. Some just look for a particular action like someone unlocking their car door, others might have access to more context like someone who isn’t the owner of the car unlocking the door. Going even further some detections might look at how the car door was opened or at what
Read more

Endpoint on Adrenaline 3

Image
Introduction Now that I have covered the advanced features obtained from Defender for Cloud and the complexities of Defender for Endpoint with the objective of delivering as much protection as possible to the endpoint, I will now explore how to expand on this greatly and open up even more use cases. Microsoft Sentinel This technology will allow us to unify and correlate data generated by other controls. I have decided to deploy Microsoft Sentinel into 4 primary categories : System Administrator - Asset Uptime, Application Inventory, Device configuration and Troubleshooting Network Engineers - Netflow and session traffic, violations and alerts for potential issues Threat Detection - Analytics and playbooks Threat hunting - Workbooks & Machine learning Using Microsoft Sentinel we can achieve a plethora of incredibly powerful use cases with Defender 365 endpoint data. Below is an illustration of how my SIEM works to enable analysts to prevent and detect threats Data Sources In order t
Read more

Endpoint on Adrenaline Two

Image
Introduction Continuing on from my last post that captured using Defender for Cloud to gain powerful additional features on top of defender for endpoint to protect your endpoints we are going to take a closer look at Defender for Endpoint itself and extend into some endpoint-specific use cases for Defender for Identity that tie directly back into Defender for Endpoint. Firstly a really important consideration when configuring Defender for Endpoint is that alot of the heavy lifting from a prevention standpoint actually happens in Defender Anti virus. This means that while im going to briefly cover some settings to make sure Defender Anti Virus isnt hindering Defender for Endpoint im going to reserve further Defender Anti Virus controls to the next part in this series. This also of course means that when your doing your own testing just installing the MSSense agent (What you get from the scripts, intune etc) is actually not Defender for Endpoint in its totality so you simply can not m
Read more

Investigate Two

Image
Introductions How you as an analyst handle true positives is life and death in the eyes of potential victims. Traditionally the industry elected to prioritize overzealousness and sending more than not to cover their failings, This however is no different to guesses and it is possible to arrive at strong data-backed decisions on events that could be the compromise of an estate True Positive True positives exist at the heart of all our jobs, they are what we wake up for in the morning and why we endlessly pursue understanding how to protect our clients. The strictest possible definition of true positive is where an outcome of a prediction or model is returned true. This broad definition is important because the assumption carried with a predication or model can change. As an example many security technologies aim to identify when an application often unwanted by an organization is present within a system, these are commonly dubbed PUPs. (Potentially Unwanted Programs). The general cons
Read more

Securing your estate: The First Step

Introduction A commonly forgotten fact within the cybersecurity industry is that most organizations are not equipped nor have started to form any sort of security program. This is the case for many reasons because most organizations are SMBs so they don't and likely will never have funds to purchase people and technology and the fact that the cybersecurity industry is incredibly toxic for low expertise and or low capability teams as the well of knowledge we all rely on has been poisoned by vendors and 'thought leaders'. With this in mind, I have created a small resource that will guide you through what you need to do to make a start. This resource won't reference vendors and I will try to avoid specific jargon. Enumerate The term 'You can't secure what you don't know' stands strong even to this day and should be your primary focus before you do anything else. Understanding what assets, you have both physically (computer hardware) and logically (applicati
Read more

Standardized Note Taking Format For Analysts

Image
  Introduction This post outlines a format for note-taking designed to aid analysts and ensure the knowledge they acquire over time is kept so that it can easily be consumed later. This format is designed to be technology agnostic so it can be applied to a note-taking tool or platform of the analyst’s choice. I designed this format because analysts often received what you could call unplanned information whereby at any given moment during their day they could learn something highly impactful to their role via any medium. This really exasperates the need for good note-taking practices for analysts. Illustrated above is the wireframe that analysts can implement into their note-taking platforms. Each section contains sub-sections that allow for different knowledge to remain segregated and more searchable. Meeting Notes Within any given week analysts can have countless meetings and so it is important to note down items from meetings for future review. Not every meeting needs to be capt
Read more

Attack Simulations for your SOC

Image
 Introduction SOC analysts spend 99 percent of their time looking at the same data and patterns over and over again. They develop muscle memory that helps them use their platforms without much effort but also in grains in them potentially poor practices. Most analysts are new to the industry and are taking certifications like CompTIA Cysa+ and Azure SC200 but none of these certifications teach them what genuine malicious actions look like. So how do you train a team of people how to detect malicious activity and respond in the ever-morphing threat landscape? You throw them through the ring of fire. You make them triage real (as close as possible) incidents and appropriately monitor their behavior and progress to tune the processes perpetually. Analysts are arguably the single most important role within a SOC, they carry the burden of triaging alerts and correctly identifying whether malicious activity is occurring. They are the first, middle and last line of defense. However, despite t
Read more