From c241601fa97a6ee5ab270a8c4be213651837e348 Mon Sep 17 00:00:00 2001 From: Florian Roth Date: Mon, 6 Dec 2021 13:45:59 +0100 Subject: [PATCH] fix: FPs noticed with Aurora --- .../process_access/sysmon_in_memory_assembly_execution.yml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/rules/windows/process_access/sysmon_in_memory_assembly_execution.yml b/rules/windows/process_access/sysmon_in_memory_assembly_execution.yml index 3f809d057..1c814378d 100644 --- a/rules/windows/process_access/sysmon_in_memory_assembly_execution.yml +++ b/rules/windows/process_access/sysmon_in_memory_assembly_execution.yml @@ -3,7 +3,7 @@ id: 5f113a8f-8b61-41ca-b90f-d374fa7e4a39 description: Detects the access to processes by other suspicious processes which have reflectively loaded libraries in their memory space. An example is SilentTrinity C2 behaviour. Generally speaking, when Sysmon EventID 10 cannot reference a stack call to a dll loaded from disk (the standard way), it will display "UNKNOWN" as the module name. Usually this means the stack call points to a module that was reflectively loaded in memory. Adding to this, it is not common to see such few calls in the stack (ntdll.dll --> kernelbase.dll --> unknown) which essentially means that most of the functions required by the process to execute certain routines are already present in memory, not requiring any calls to external libraries. The latter should also be considered suspicious. status: experimental date: 2019/10/27 -modified: 2021/12/04 +modified: 2021/12/06 author: Perez Diego (@darkquassar), oscd.community, Jonhnathan Ribeiro references: - https://azure.microsoft.com/en-ca/blog/detecting-in-memory-attacks-with-sysmon-and-azure-security-center/ @@ -65,6 +65,8 @@ detection: - SourceImage: - 'C:\Users\\*\AppData\Local\Programs\Microsoft VS Code\Code.exe' - 'C:\WINDOWS\system32\taskhostw.exe' + - TargetImage: + - 'C:\Windows\System32\RuntimeBroker.exe' condition: ( selection1 or selection2 or selection3 ) and not filter fields: - ComputerName