SigmaHQ/rules/windows/sysmon/sysmon_in_memory_assembly_execution.yml
Thomas Patzke 8d6a507ec4 OSCD QA wave 1
* Checked all rules against Mordor and EVTX samples datasets
* Added field names
* Some severity adjustments
* Fixes
2020-01-11 00:11:27 +01:00

48 lines
1.9 KiB
YAML

title: Suspicious In-Memory Module Execution
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: 27/10/2019
author: Perez Diego (@darkquassar), oscd.community
references:
- https://azure.microsoft.com/en-ca/blog/detecting-in-memory-attacks-with-sysmon-and-azure-security-center/
tags:
- attack.privilege_escalation
- attack.t1055
logsource:
product: windows
service: sysmon
detection:
selection_01:
EventID: 10
CallTrace:
- "C:\\Windows\\SYSTEM32\\ntdll.dll+*|C:\\Windows\\System32\\KERNELBASE.dll+*|UNKNOWN(*)"
- "*UNKNOWN(*)|UNKNOWN(*)"
selection_02:
EventID: 10
CallTrace: "*UNKNOWN*"
granted_access:
GrantedAccess:
- "0x1F0FFF"
- "0x1F1FFF"
- "0x143A"
- "0x1410"
- "0x1010"
- "0x1F2FFF"
- "0x1F3FFF"
- "0x1FFFFF"
condition: selection_01 OR (selection_02 AND granted_access)
fields:
- ComputerName
- User
- SourceImage
- TargetImage
- CallTrace
level: critical
falsepositives:
- Low