Author Michah Babinski
Originally published on Medium, November 23, 2022
Introduction
In this article, I’ll discuss the importance of a repeatable, easy-to-follow process for detection engineering, and give an example walkthrough of my process based on a recent alert from the Cybersecurity and Infrastructure Security Administration (CISA) regarding Hive ransomware group. This is intended for folks who are new to (or interested in) detection engineering, or those who pursue detection engineering outcomes but may lack the time and resources to do it at a very deep level. Think of this as “Detection Engineering for the Rest of Us” — practical, educational, and effective. The detection rules presented at the end do overlap with existing open-source rules; however, they do contain unique elements which set them apart. Whether you are new to detection engineering or highly experienced, I hope you get something out of it!
Definition
By “detection engineering,” I mean researching, developing, and managing threat detection content relevant to a specific, actionable cyber threat that applies to an organization or community.
Detection Engineering Goals
This is an emerging discipline, with several definitions floating around, so if my definition from the previous sentence is not to your liking, please let me know! I am early on in my threat detection journey and always love hearing from those with different perspectives. A common thread throughout all these definitions, however, is that detection engineering differs from simply cramming new alert rules into a SIEM (Security Information and Event Management). It is a targeted, purposeful approach that seeks to build detection capabilities that are:
Resilient (able to detect malicious activity even when attackers modify their procedures)
Relevant (specifically applicable to the threats which may affect the technologies, platforms, and environmental context of an organization)
Efficient (achieving a good balance of coverage without an unduly high false positive rate)
Actionable (providing meaningful follow-up analysis steps for an analyst or customer to follow to determine whether the alert is a true positive, and if so, how they ought to initiate incident response)
The Importance of Repeatability
Like all security professionals, we detection engineers usually have a full plate. Developing and curating detection content is a big responsibility, and with new threats emerging and morphing, it’s difficult to meet the demand. Of course, we should all explore (and hopefully adopt) a “detection as code” approach, and gain as much value as possible from automation for our organizations and customers. However, there are limits to the extent to which we can automate the threat detection process (I believe this for all areas of cybersecurity). Even the best sources of in-depth threat intelligence and intrusion reporting (including those that provide Sigma rules for efficient signature sharing) still require research, testing, and contextualizing by a trained detection engineer to meet the goals listed in the bullet list above.
So, to provide good detection content at a pace that meets the demand we need repeatable processes for learning about new threats, developing content, and putting that into action. Below, I’ll share my process using a recent example: Hive ransomware.
Step 1: Start with a Good Source
If you have an in-house threat intelligence team, purple team, or other crack squad of cyber pros who can feed you raw, up-to-the-minute intel, good for you! You are ahead of the curve and someone I should be learning from. For the rest of us, we can rely on threat intelligence reports from the best in the business: sources like The DFIR Report, Red Canary, Mandiant, Crowdstrike, Trellix, and CISA.
For this example, I used an alert from CISA that came out a few days ago:
#StopRansomware: Hive Ransomware. I gave it a quick read and was instantly reminded of this video I saw recently:
A worthwhile diversion from the detection engineering process
Step 2: Identify the Opportunities
After screening that awesome dance video yet again I refocused on the CISA alert, zeroing in on the “Known IOCs — Logged Processes” section:
Some of these commands (wmic and vssadmin) I am familiar with, while others (wevtutil and bcdedit) are new to me. I’ll focus on these commands because they seem like built-in system utilities that an attacker could use to further their goals without attracting too much attention.
I find these types of detection opportunities attractive because they involve Living off the Land (LotL), where attackers take advantage of built-in commands and utilities on a compromised system. This way, they can progress toward their goal of deploying ransomware with a lower probability of triggering antivirus or EDR solutions (or attracting the attention of an overworked rookie security analyst).
Step 3: Do a bit of Research
wevtutil
A good first stop for this type of research is the LOLBAS project, which aims to “document every binary, script, and library that can be used for Living Off the Land Techniques.” I checked their site, https://lolbas-project.github.io/#, but didn’t find either wevtutil or bcdedit, unfortunately.
The next step was good old Microsoft Learn. I found the helpful page on wevtutil and learned that it is a way of managing the Windows event log, including functionality to potentially disable, clear, or modify the configuration of an event log in a way that would degrade its usefulness to a defender. Based on the documentation, I am interested in testing (and detecting) the following options:
set-log/sl: Looks like one could alter the settings of a log to make it not useful.
uninstall-manifest/um: I have no idea what this manifest is, but uninstalling it will mess with the logging?
clear-log/cl: This one is obvious, as clearing the log is a classic example of “Indicator Removal on Host” and is the exact option used in the CISA alert.
I’ll make a note of these options then turn my attention to the other utility,
bcdedit
These commands required a bit more research, as I am less familiar with the Boot Configuration Data (BCD) which configures system boot settings. By investigating bcdedit in Mitre ATT&CK framework and the Cyber Analytics Repository (in conjunction with Microsoft Learn documentation), I determined that the two bcdedit options referenced in the CISA alert are used to disrupt system recovery in the event of corruption, in this case Windows Recovery Environment (WinRE). They do this by causing the system to ignore failed boot signals which would prompt the system to enter WinRE, and then disabling WinRE entirely. Creating a SIEM alert rule to look for bcdedit.exe with these command-line options would be good. But after reading this recent article from NVISO labs, I hoped to add a registry modification to my detection, in case the rule based on the process creation event was evaded.
Step 4: Develop and Test!
Now the fun begins! I’d like to run some of these commands in my own lab environment and play with the options, to make my detection dreams into reality. Luckily, we detection engineers have a lot of great, low-effort/high-value options for simple home lab setups. I use https://detectionlab.network/, which includes a mini sysmon-enabled Active Directory environment, Splunk instance, plus a bunch of other cool detection-related tools that I haven’t yet had the chance to explore.
wevtutil
After a bit of tinkering (ok, an embarrassing amount of tinkering), I was able to disable sysmon (😨) using the following command:
But we don’t stop there! Let’s try some variations that could disable or otherwise degrade a given log (note the subtle or not-so-subtle differences in syntax):
I never did figure out the uninstall manifest option. I found a blog post that describes ways it can be abused but didn’t really follow it well enough to be an efficient use of my research time.
bcdedit
Bcdedit proved more interesting — in addition to the commands which were included in the CISA article, I determined that additional command line options could be used in conjunction with the /set flag to similarly cause the system to ignore various types of boot failures. For example, the following three commands, while sufficiently different than the example from the CISA article, could have a similar cumulative effect:
Finally, my research into bcdedit yielded an interesting blog from NVISO which explored the registry values set when the bcdedit utility is used to disrupt boot procedures. They uncover a pure registry (no use of bcdedit.exe required) method to accomplish the same objective, as illustrated in the detection logic below:
Step 5: Document and Share
With my research and lab tests complete, log data generated, and my criteria for good detection content (from earlier in the article) in mind, I am ready to document these concepts in the form of Sigma rules, which can be easily shared with the community and converted into the SIEM query format of choice.
Sigma: I love it, you love it I include these rules here: https://github.com/mbabinski/Sigma-Rules/tree/main/2022_Hive_Ransomware A couple things to note:
The use of the windash modifier and registry rule increases the resilience of the detections, since most Windows command-line utilities treat /set and -set equally!
Note that the windash modifier only works with pySigma, the new and improved codebase on which Sigma is built.
The inclusion of a description, Mitre ATT&CK framework tags, and references increases the relevance and efficiency of the rules. This also makes them more actionable; analysts can quickly research the relevant TTPs (Tactics, Techniques, and Procedures) and determine the best course of action.
Here’s an example of one of the rules:
Conclusion
There you have it! My detection engineering process in a nutshell. I have a lot to learn and improve upon, particularly my lab setup. I’d like to develop a script that will directly convert my draft Sigma rules into Splunk (or whatever) searches, execute the commands in my lab environment, and report on whether the activity was detected in the search results. For that I believe that the Splunk SDK will be my weapon of choice. I’ll also need to write a pySigma backend for the SIEM product that I use at work (like I did at my last job), as one does not yet exist.
Stay tuned, and as always, happy analyzing! 🧐 About the Author: Micah Babinski is a security professional living in Portland, OR, working as a threat detection engineer for Zyston, LLC. After 10 years working in the Geographic Information Systems (GIS) profession, Micah pivoted to security in 2020, pursuing an interest that developed since sitting next to and befriending the InfoSec team when he worked for the City of Portland. Micah's interests in security are threat detection, incident response, automation, system integration, and interoperability. Micah believes that personal connections, between and among security professionals and the users and customers they serve, is the key to success. Besides cybersecurity, Micah enjoys playing Scottish bagpipes, traveling, baking, and going on back country adventures in the Pacific Northwest and beyond.