Catching a Wev(tutil): Threat Detection for the Rest of Us

Wow, look at that wave (Image Credit: Unsplash)

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 fairly 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 reasonably 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. It’s 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 effect 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 all the time, 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, I believe there are limits to the extent to which we can automate the threat detection process (actually 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 in order 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 probably 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.

With this logo, you know CISA isn’t messing around

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:

Image Credit: CISA

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 type of detection opportunities attractive because they involve Living off the Land (LotL), where attackers take advantage of built-in commands and utilities on a comromised 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 basically 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 possibly 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 maybe uninstalling it will mess with the logging?
• clear-log/cl: This one is fairly 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:

wevtutil set-log Microsoft-Windows-Sysmon/Operational -e:false

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):

wevtutil set-log Microsoft-Windows-Sysmon/Operational /e:false
wevtutil sl Microsoft-Windows-Sysmon/Operational -e:false
wevtutil sl Microsoft-Windows-Sysmon/Operational -ms:90000 # reduces log size
wevtutil cl Microsoft-Windows-Sysmon/Operational
wevtutil clear-log Microsoft-Windows-Sysmon/Operational

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 somewhat 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:

bcdedit /set {default} bootstatuspolicy IgnoreShutdownFailures
bcdedit /set {default} bootstatuspolicy IgnoreCheckpointFailures
bcdedit /set {default} bootstatuspolicy IgnoreBootFailures

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 essentially uncover a pure registry (no use of bcdedit.exe required) method to accomplish the same objective, as illustrated in the detection logic below:

Image Credit: NVISO

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 rule 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 and determine the best course of action.

Here’s an example of one of the rules:

title: Event Log Manipulation Using Wevtutil
id: 4d71069b-dda7-4df7-b835-1f23dd212615
status: experimental
description: Detects the use of wevtutil to clear or otherwise manipulate Windows event logs.
references:
    - https://www.cisa.gov/uscert/ncas/alerts/aa22-321a
author: Micah Babinski
date: 2022/11/22
tags:
    - attack.defense_evasion
    - attack.t1070
    - attack.g0092
logsource:
    category: process_creation
    product: windows
detection:
    selection_exe:
        Image|endswith: '\wevtutil.exe'
    selection_clear:
        CommandLine|contains:
            - ' cl '
            - 'clear-log'
    selection_set:
        CommandLine|contains:
            - ' sl '
            - 'set-log'
    selection_set_flags:
        CommandLine|contains|windash: 
            - '/e:false'
            - '/ms:'
    condition: selection_exe and (selection_clear or (selection_set and selection_set_flags))
falsepositives:
    - Unknown
level: high

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 or not 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! 🧐