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.
YARA Rule
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"