darkquasar
37 lines
1.7 KiB
YAML
37 lines
1.7 KiB
YAML
title: Suspicious In-Memory Module Execution
|
|
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)
|
|
level: critical
|
|
falsepositives:
|
|
- Low
|