Deploy, Test, Monitor: Mastering Microsoft Defender ASR with Atomic Techniques in Splunk

Adversaries constantly seek new methods to breach endpoint security, making it essential to minimize potential points of attack, vigilantly monitor events, and regularly test defenses to confirm their effectiveness. This proactive approach ensures preparedness against evolving cyber threats.

Check out ASRGEN and ASRGEN 1.0 Release blog for more ASR action

Enter Microsoft Defender Attack Surface Reduction (ASR), a frontline defense tool in the cybersecurity arsenal. Defender ASR plays an important role in reducing the attack surface of Windows systems, making it harder for adversaries to evade controls. ASR provides proactive protection against a variety of attack vectors, including malicious scripts, ransomware, and untrusted processes. By implementing rules that restrict potentially harmful behaviors and actions on devices, Defender ASR significantly enhances an organization’s security posture. Its integration into the broader Microsoft Defender suite ensures a holistic and layered defense strategy, crucial for combating cyber threats. In essence, Microsoft Defender ASR isn’t just a tool; it’s a component to reduce the attack surface enough that defenders gain an advantage.

In this blog, the Splunk Threat Research Team will delve into the details of Microsoft Defender ASR’s role in reducing the attack surface. Our analysis includes:

• Deploying Microsoft Defender ASR: Step-by-step guidance on effective implementation
• Atomic Testing with Defender ASR: Exploring how to test and validate the system’s security measures
• Understanding ASR Rule Configurations: A closer examination of ASR rules and their impact
• Advanced Monitoring Techniques in Splunk: Strategies for leveraging Splunk to enhance security monitoring

What is Microsoft Defender ASR?

Defender ASR is designed to identify and block potentially malicious activities even before they can occur, thereby proactively preventing the exploitation of system vulnerabilities. Some of its key features include:

• Event ID 1121 shows the blocking of disallowed operations.
• Event ID 1122 indicates auditing of such operations for review and analysis.
• Event IDs 1131 and 1133 illustrate ASR’s capability to block unauthorized operations.
• Event IDs 1132 and 1134 offer audit logs for these operations, adding an extra layer of monitoring.

Using the PowerShell command

(Get-WinEvent -ListProvider "Microsoft-Windows-Windows Defender").Events | Format-Table Id, Description

helps administrators extract detailed logs of these events, enabling them to pinpoint specific security incidents and understand the context behind alerts.

Microsoft Defender ASR employs three critical strategies — Block (enabled), Warn, and Audit — each serving a unique purpose.

Block: The First Line of Defense

• The ‘Block’ feature is Defender ASR’s most assertive action. It outright prevents potentially harmful operations or processes from executing.
• For instance, when Defender ASR blocks unauthorized operations (as indicated by Event ID 1131) or dangerous network connections (Event ID 1126), it actively stops these threats in their tracks, offering immediate protection against known risks.
• The blocking action is crucial in scenarios where immediate intervention is required to prevent potential security breaches.

Warn: Balancing Security with User Autonomy

• The ‘Warn’ feature is designed to alert users when a potentially risky activity is detected, while still offering the choice to proceed.
• This approach is particularly effective in environments where user discretion is necessary. It empowers users to make informed decisions based on the context, albeit with a cautionary note about the potential risks involved.
• The warning mechanism helps maintain a balance between strict security measures and operational flexibility, allowing users to override certain decisions when deemed appropriate.

Audit: Keeping a Watchful Eye

• The ‘Audit’ mode in Defender ASR provides a record of events and operations that take place. Rather than blocking or warning, it logs activities for later review and analysis.
• Audit logs are invaluable for post-event analysis, helping security teams understand the nature of attempted operations and identify patterns that could indicate emerging threats.
• Event IDs like 1122 and 1132 exemplify the audit function, offering insights into operations that were either executed or blocked, thereby enabling a retrospective assessment of security incidents.

Microsoft Defender ASR goes beyond being just a tool; it’s a strategic asset crucial for controlling and minimizing vulnerability in digital environments. Its capabilities in detecting, preventing, and shedding light on security threats render it an essential element in any strong security setup.

Get ASR in Splunk

Integrating Microsoft Defender’s Operational logs into Splunk can be achieved with a simple modification to your existing or new inputs.conf:

[WinEventLog://Microsoft-Windows-Windows Defender/Operational] 
disabled = 0 
renderXml = True 
sourcetype = XmlWinEventLog:Microsoft-Windows-Windows Defender/Operational 
index = win

In our tests, we’ve found that both multi-line and XML formats work effectively with the provided analytics, but adjustments may be necessary. The Operational logs offer extensive insight into Defender’s activities. Therefore, while collecting all data can be beneficial for comprehensive visibility, you may prefer to focus specifically on ASR-related events.

To narrow down the data collection to ASR-specific behaviors, you can refine the inputs.conf as follows:

[WinEventLog://Microsoft-Windows-Windows Defender/Operational] 
disabled = 0 
renderXml = 0 
sourcetype = XmlWinEventLog:Microsoft-Windows-Windows Defender/Operational 
index = win 
whitelist = 1121|1122|1125|1126|1129|1131|1132|1133|1134|5007

This configuration restricts the data collection to only the ASR event codes (1121, 1122, 1125, and so forth), enabling a more targeted approach in monitoring and analysis within Splunk.

Now that we are collecting the events, how do we know this is actually working? Let’s now enable ASR and perform some Atomic Testing.

Enable Attack Surface Reduction Rules

Depending on your organization and strategy, placing into Audit mode may be the most effective way to generate events, monitor, tune and add exclusions. This will be a cyclical process until the environment is at a place where block (or enabled) is the default. Also, depending on your organization, you may have the opportunity to use InTune or Windows Group Policy to deploy ASR. More information may be found on the official ASR docs page here. In this blog, we will focus on the PowerShell implementation of ASR and highlight its usage.

Following, here is a simple table showcasing each ID with their respective name:

In PowerShell, we can enable and manage ASR with the following cmdlets — Set-MpPreference and Get-MpPreference. Let’s check out how to use the cmdlets next.

ASR Modes

Now, if you are interested in just enabling everything in a specific mode, it’s possible with the following command, however, note that this expects you have 1 or all enabled already.

If you would like to enable all of them for the first time, the following command includes each ASR ID and will set them to mode as expected:

Enable

$asrRuleIds = @{ "56A863A9-875E-4185-98A7-B882C64B5CE5" = "Block abuse of exploited vulnerable signed drivers"; "7674BA52-37EB-4A4F-A9A1-F0F9A1619A2C" = "Block Adobe Reader from creating child processes"; "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = "Block all Office applications from creating child processes"; "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" = "Block credential stealing from the Windows local security authority subsystem (lsass.exe)"; "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = "Block executable content from email client and webmail"; "01443614-CD74-433A-B99E-2ECDC07BFC25" = "Block executable files from running unless they meet a prevalence, age, or trusted list criterion"; "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC" = "Block execution of potentially obfuscated scripts"; "D3E037E1-3EB8-44C8-A917-57927947596D" = "Block JavaScript or VBScript from launching downloaded executable content"; "3B576869-A4EC-4529-8536-B80A7769E899" = "Block Office applications from creating executable content"; "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84" = "Block Office applications from injecting code into other processes"; "26190899-1602-49E8-8B27-EB1D0A1CE869" = "Block Office communication application from creating child processes"; "E6DB77E5-3DF2-4CF1-B95A-636979351E5B" = "Block persistence through WMI event subscription"; "D1E49AAC-8F56-4280-B9BA-993A6D77406C" = "Block process creations originating from PSExec and WMI commands"; "B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4" = "Block untrusted and unsigned processes that run from USB"; "92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B" = "Block Win32 API calls from Office macros"; "C1DB55AB-C21A-4637-BB3F-A12568109D35" = "Use advanced protection against ransomware"; "A8F5898E-1DC8-49A9-9878-85004B8A61E6" = "Block Webshell creation for Servers"; } foreach ($id in $asrRuleIds.Keys) { Add-MpPreference -AttackSurfaceReductionRules_Ids $id -AttackSurfaceReductionRules_Actions Enabled } Write-Host "All specified ASR rules have been set to Enabled."

AuditMode

$asrRuleIds = @{ "56A863A9-875E-4185-98A7-B882C64B5CE5" = "Block abuse of exploited vulnerable signed drivers"; "7674BA52-37EB-4A4F-A9A1-F0F9A1619A2C" = "Block Adobe Reader from creating child processes"; "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = "Block all Office applications from creating child processes"; "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" = "Block credential stealing from the Windows local security authority subsystem (lsass.exe)"; "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = "Block executable content from email client and webmail"; "01443614-CD74-433A-B99E-2ECDC07BFC25" = "Block executable files from running unless they meet a prevalence, age, or trusted list criterion"; "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC" = "Block execution of potentially obfuscated scripts"; "D3E037E1-3EB8-44C8-A917-57927947596D" = "Block JavaScript or VBScript from launching downloaded executable content"; "3B576869-A4EC-4529-8536-B80A7769E899" = "Block Office applications from creating executable content"; "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84" = "Block Office applications from injecting code into other processes"; "26190899-1602-49E8-8B27-EB1D0A1CE869" = "Block Office communication application from creating child processes"; "E6DB77E5-3DF2-4CF1-B95A-636979351E5B" = "Block persistence through WMI event subscription"; "D1E49AAC-8F56-4280-B9BA-993A6D77406C" = "Block process creations originating from PSExec and WMI commands"; "B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4" = "Block untrusted and unsigned processes that run from USB"; "92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B" = "Block Win32 API calls from Office macros"; "C1DB55AB-C21A-4637-BB3F-A12568109D35" = "Use advanced protection against ransomware"; "A8F5898E-1DC8-49A9-9878-85004B8A61E6" = "Block Webshell creation for Servers"; } foreach ($id in $asrRuleIds.Keys) { Add-MpPreference -AttackSurfaceReductionRules_Ids $id -AttackSurfaceReductionRules_Actions AuditMode } Write-Host "All specified ASR rules have been set to AuditMode."

Warn

$asrRuleIds = @{ "56A863A9-875E-4185-98A7-B882C64B5CE5" = "Block abuse of exploited vulnerable signed drivers"; "7674BA52-37EB-4A4F-A9A1-F0F9A1619A2C" = "Block Adobe Reader from creating child processes"; "D4F940AB-401B-4EFC-AADC-AD5F3C50688A" = "Block all Office applications from creating child processes"; "9E6C4E1F-7D60-472F-BA1A-A39EF669E4B2" = "Block credential stealing from the Windows local security authority subsystem (lsass.exe)"; "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550" = "Block executable content from email client and webmail"; "01443614-CD74-433A-B99E-2ECDC07BFC25" = "Block executable files from running unless they meet a prevalence, age, or trusted list criterion"; "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC" = "Block execution of potentially obfuscated scripts"; "D3E037E1-3EB8-44C8-A917-57927947596D" = "Block JavaScript or VBScript from launching downloaded executable content"; "3B576869-A4EC-4529-8536-B80A7769E899" = "Block Office applications from creating executable content"; "75668C1F-73B5-4CF0-BB93-3ECF5CB7CC84" = "Block Office applications from injecting code into other processes"; "26190899-1602-49E8-8B27-EB1D0A1CE869" = "Block Office communication application from creating child processes"; "E6DB77E5-3DF2-4CF1-B95A-636979351E5B" = "Block persistence through WMI event subscription"; "D1E49AAC-8F56-4280-B9BA-993A6D77406C" = "Block process creations originating from PSExec and WMI commands"; "B2B3F03D-6A65-4F7B-A9C7-1C7EF74A9BA4" = "Block untrusted and unsigned processes that run from USB"; "92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B" = "Block Win32 API calls from Office macros"; "C1DB55AB-C21A-4637-BB3F-A12568109D35" = "Use advanced protection against ransomware"; "A8F5898E-1DC8-49A9-9878-85004B8A61E6" = "Block Webshell creation for Servers"; } foreach ($id in $asrRuleIds.Keys) { Add-MpPreference -AttackSurfaceReductionRules_Ids $id -AttackSurfaceReductionRules_Actions Warn } Write-Host "All specified ASR rules have been set to Warn."

Stack ASR IDs

With ASR, we can also specify one or many to enable at once. Here are some example:

Enable:
1. Block JavaScript or VBScript from launching downloaded executable content

2. Block Adobe Reader from creating child processes

3. Block abuse of exploited vulnerable signed drivers

Set-MpPreference -AttackSurfaceReductionRules_Ids 56A863A9–875E-4185–98A7-B882C64B5CE5,7674BA52–37EB-4A4F-A9A1-F0F9A1619A2C,D3E037E1–3EB8–44C8-A917–57927947596D -AttackSurfaceReductionRules_Actions AuditMode

Exclusions

Now for these rules we can enable exclusions globally or per rule. This is how to perform those actions:

Per-Rule Exclusion

Set-MpPreference -AttackSurfaceReductionRules_Ids 56A863A9–875E-4185–98A7-B882C64B5CE5 -AttackSurfaceReductionOnlyExclusions -Exclusions c:\temp*.sys

Global Exclusion

Set-MpPreference -AttackSurfaceReductionOnlyExclusions -Exclusions c:\temp\.sys

Verify

To verify the rules are enabled accordingly, we can run the following:

$asrSettings = Get-MpPreference | Select-Object AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions
for ($i=0; $i -lt $asrSettings.AttackSurfaceReductionRules_Ids.Count; $i++) {
Write-Host ("Rule ID: " + $asrSettings.AttackSurfaceReductionRules_Ids[$i] + " - Action: " + $asrSettings.AttackSurfaceReductionRules_Actions[$i])
}

Exclusions

Once a exclusion is created, verification may be performed with the following:

Get-MpPreference | Select-Object AttackSurfaceReductionOnlyExclusions

Now that we have gone through enabling ASR in one of 3 modes and providing any exclusions, we’ll now jump into Atomic testing.

Atomic Testing

Now that ASR Rules, one or many are in a state — block, audit, warn, how do we know these actually work? Let’s test 3 ASR rules and review the data in Splunk.

Atomic Test 1

Block all Office applications from creating child processes (D4F940AB-401B-4EFC-AADC-AD5F3C50688A)

Our first Atomic test will utilize a basic Windows Word macro that is meant to generate the telemetry trace we need to ensure ASR in the mode we selected is operational.

Macro:

Sub wshell_exec() Set wsh = CreateObject("wscript.shell") wsh.Run "powershell.exe", 1 End Sub

Place this into a new macro in Microsoft Word and run it.

In this test instance this rule is set to block, and the result when the macro is executed it is immediately blocked.

Atomic Test 2

Block Office applications from creating executable content (3B576869-A4EC-4529–8536-B80A7769E899)

In this Atomic test, will will utilize the following macro to write a vbs file to disk and attempt to run it.

Sub Auto_Open() Dim fso As Object Set fso = CreateObject("Scripting.FileSystemObject") Dim oFile As Object Dim TmpFolder As Object Set TmpFolder = fso.GetSpecialFolder(2) Set oFile = fso.CreateTextFile(TmpFolder & "\script.vbs") oFile.WriteLine "Set wsh = CreateObject('wscript.shell')" oFile.WriteLine "wsh.Run 'calc.exe', 1" oFile.Close End Sub

In this test, ASR is set to Warn, therefore it is up to the reviewer to “Unblock” ASR to allow the activity to continue or Block it.

Atomic Test 3

Block process creations originating from PSExec and WMI commands (D1E49AAC-8F56–4280-B9BA-993D77406C)

In our final test, we will download and run PSexec to connect to the local system to spawn a new process. This behavior should be blocked.

Invoke-WebRequest -Uri "https://live.sysinternals.com/PsExec64.exe" -OutFile "PsExec64.exe"; .\PsExec64.exe -accepteula \\localhot cmd

For this test, it was enabled in Audit and later Block mode.

Security Content

For Splunk Security Content, a new analytic story and security content was generated to assist defenders. The content is a mix of anomaly, hunting and TTP. Ensure during your deployment of ASR, modify and tune the analytics as needed for your organization.

Windows Defender ASR Audit Events

This detection searches for Windows Defender ASR audit events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR audit events that are generated when a process or application attempts to perform an action that would be blocked by an ASR rule, but is allowed to proceed for auditingpurposes.

`ms_defender` EventCode IN (1122, 1125, 1126, 1132, 1134) | lookup asr_rules ID OUTPUT ASR_Rule | fillnull value=NULL | stats count min(_time) as firstTime max(_time) as lastTime by host, Process_Name, Target_Commandline, Path, ID, EventCode, ASR_Rule | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Windows Defender ASR Block Events

This detection searches for Windows Defender ASR block events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR block events that are generated when a process or application attempts to perform an action that is blocked by an ASR rule. Typically, these will be enabled in block most after auditing and tuning the ASR rules themselves. Set to TTP once tuned.

`ms_defender` EventCode IN (1121, 1126, 1129, 1131, 1133) lookup asr_rules ID OUTPUT ASR_Rule fillnull value=NULL stats count min(_time) as firstTime max(_time) as lastTime by host, Path, Parent_Commandline, Process_Name, ID, EventCode, ASR_Rule `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Windows Defender ASR Registry Modification

This detection searches for Windows Defender ASR registry modification events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR registry modification events that are generated when a process or application attempts to modify a registry key that is blocked by an ASR rule. Typically, these will be enabled in block most after auditing and tuning the ASR rules themselves. Set to TTP once tuned.

`ms_defender` EventCode IN (5007) rex field=New_Value "0x(?\d+)$" rex field=Old_Value "0x(?\d+)$" rex field=New_Value "Rules\\\\(?[A-Fa-f0-9\\-]+)\\s*=" lookup asr_rules ID AS ASR_ID OUTPUT ASR_Rule eval New_Registry_Value=case(New_Registry_Value=="0", "Disabled", New_Registry_Value=="1", "Block", New_Registry_Value=="2", "Audit", New_Registry_Value=="6", "Warn") eval Old_Registry_Value=case(Old_Registry_Value=="0", "Disabled", Old_Registry_Value=="1", "Block", Old_Registry_Value=="2", "Audit", Old_Registry_Value=="6", "Warn") stats count min(_time) as firstTime max(_time) as lastTime by host, New_Value, Old_Value, Old_Registry_Value, New_Registry_Value, ASR_Rule `security_content_ctime(firstTime)`

Windows Defender ASR Rule Disabled

The following analytic identifies when a Windows Defender ASR rule disabled events. ASR is a feature of Windows Defender Exploit Guard that prevents actions and apps that are typically used by exploit-seeking malware to infect machines. ASR rules are applied to processes and applications. When a process or application attempts to perform an action that is blocked by an ASR rule, an event is generated. This detection searches for ASR rule disabled events that are generated when an ASR rule is disabled.

`ms_defender` EventCode IN (5007) rex field=New_Value "0x(?\d+)$" rex field=Old_Value "0x(?\d+)$" rex field=New_Value "Rules\\\\(?[A-Fa-f0-9\\-]+)\\s*=" lookup asr_rules ID AS ASR_ID OUTPUT ASR_Rule eval New_Registry_Value=case(New_Registry_Value=="0", "Disabled", New_Registry_Value=="1", "Block", New_Registry_Value=="2", "Audit", New_Registry_Value=="6", "Warn") eval Old_Registry_Value=case(Old_Registry_Value=="0", "Disabled", Old_Registry_Value=="1", "Block", Old_Registry_Value=="2", "Audit", Old_Registry_Value=="6", "Warn") search New_Registry_Value="Disabled" stats count min(_time) as firstTime max(_time) as lastTime by host, New_Value, Old_Value, Old_Registry_Value, New_Registry_Value, ASR_Rule `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Windows Defender ASR Rules Stacking

This hunting analytic targets a range of security events from Microsoft Defender, focusing on the Exploit Guard and Attack Surface Reduction (ASR) features. It monitors specific Event IDs — Event IDs 1121 and 1126 indicate active blocking of unauthorized operations or dangerous network connections, whereas Event IDs 1122 and 1125 represent audit logs for similar activities. Event ID 1129 shows user overrides on blocked operations. For ASR-related activities, Event IDs 1131 and 1133 signal blocked operations, while 1132 and 1134 are audit logs. Event ID 5007 alerts on configuration changes, possibly indicating security breaches.

`ms_defender` EventCode IN (1121, 1122, 1125, 1126, 1129, 1131, 1132, 1133, 1134, 5007) | lookup asr_rules ID OUTPUT ASR_Rule | fillnull value=NULL | stats count min(_time) as firstTime max(_time) as lastTime by host Parent_Commandline, Process_Name, Path, ID, EventCode, ASR_Rule | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`

Why Should You Care?

This blog is a critical resource for cybersecurity defenders, offering an in-depth exploration of Microsoft Defender ASR and its integration with Splunk. It highlights the significance of ASR in shrinking the attack surface, providing step-by-step guidance on deployment, atomic testing methodologies, and advanced monitoring techniques. The insights and practical examples presented are invaluable for understanding and implementing ASR’s protective measures. This knowledge is essential for defenders looking to enhance their cybersecurity posture and develop robust defenses against evolving cyber threats, making it a must-read for professionals in the field.

In Summary

In conclusion, ASR coupled with Splunk offers an unparalleled advantage in the cybersecurity landscape. Our blog has meticulously detailed how deploying, testing, and monitoring ASR rules within Splunk can significantly enhance an organization’s security posture. By delving into the practicalities of ASR, from its deployment to the intricacies of its rule configurations, we’ve provided a comprehensive guide that empowers defenders to effectively mitigate advanced cyber threats. The Atomic Testing scenarios presented illuminate the real-world efficacy of ASR rules, showcasing their vital role in safeguarding against sophisticated attacks. Integrating these insights with Splunk’s powerful monitoring capabilities creates a robust, proactive defense mechanism. This fusion not only tightens security measures but also equips cybersecurity professionals with the knowledge and tools to stay ahead in an ever-evolving threat landscape. Embracing these practices is not just a strategic move; it’s a step towards fortifying your digital fortresses against the adversaries of tomorrow.

Learn More

You can find the latest content about security analytic stories on GitHub and in Splunkbase. Splunk Security Essentials also has all these detections now available via push update.

For a full list of security content, check out the release notes on Splunk Docs.

Feedback

Any feedback or requests? Feel free to put in an issue on Github and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Michael Haag for authoring this post and the entire Splunk Threat Research Team for their contributions including Teoderick Contreras, Mauricio Velazco, Lou Stella, Bhavin Patel, Rod Soto, Eric McGinnis, and Patrick Bareiss.

Originally published at https://www.splunk.com on December 13, 2023.