The DebuggerException UnhandledFilter rule detects potential adversarial attempts to bypass debugging mechanisms by triggering unhandled exceptions in a debugger environment. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify possible evasion tactics used by attackers to obscure their activities and evade detection.
rule DebuggerException__UnhandledFilter : AntiDebug DebuggerException {
meta:
weight = 1
Author = "naxonez"
reference = "https://github.com/naxonez/yaraRules/blob/master/AntiDebugging.yara"
strings:
$ ="SetUnhandledExceptionFilter"
condition:
any of them
}
This YARA rule can be deployed in the following contexts:
Scenario: A system administrator is using GDB (GNU Debugger) to debug a critical service during an outage.
Filter/Exclusion: process.name != "gdb" or process.parent.name == "gdb" (to exclude legitimate debugging sessions)
Scenario: A Windows Task Scheduler job is running a script that temporarily triggers a debugger exception as part of a legitimate diagnostic process.
Filter/Exclusion: process.name == "schtasks.exe" or process.parent.name == "schtasks.exe"
Scenario: A Windows Debugger (WinDbg) is used by a support engineer to analyze a crash dump of a production application.
Filter/Exclusion: process.name == "windbg.exe" or process.parent.name == "windbg.exe"
Scenario: A scheduled PowerShell script is performing a system check and inadvertently triggers a debugger exception due to a third-party module.
Filter/Exclusion: process.name == "powershell.exe" and process.parent.name != "schtasks.exe"
Scenario: A remote desktop session (RDP) is being used to troubleshoot an application, and the debugger exception is a byproduct of remote debugging tools like Visual Studio Remote Debugger.
Filter/Exclusion: process.name == "msvsmon.exe" or process.parent.name == "msvsmon.exe"