Merge pull request #2814 from SigmaHQ/aurora-false-positive-fixing

fix: sadly still too many fps with this rule

rules/windows/process_access/proc_access_win_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: 2022/03/04
+modified: 2022/03/16
 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/
@@ -96,6 +96,6 @@ fields:
     - SourceImage
     - TargetImage
     - CallTrace
-level: medium # too many false positives
+level: low # too many false positives, really sad, but the amount of false positives with all kinds of software is just too high
 falsepositives:
     - SysInternals Process Explorer