Hunting For Memory Resident Malware Memhunter tool Marcos Oviedo | - - PowerPoint PPT Presentation

1

Hunting For Memory Resident Malware

Memhunter tool

Marcos Oviedo | McAfee Endpoint Software Architect

2

Agenda

• Problem Description
• Fileless Attacks Overview
• Common Injection Techniques
• Current Challenges with memory scanning detection
• Memhunter tool
• Demo

3

About me

Currently working at McAfee as a Software Architect Born and raised in Cordoba. Telecommunication Engineer. I’m really passionate about Infosec. BSides Cordoba Organizer! Speaker at Blackhat Arsenal 18 (memhunter) I’m going to be speaking at both Blackhat Arsenal 19 and Defcon 27 Demo Labs this year! Marcos Oviedo @marcosd4h

4

• The current threat landscape has evolved in attempt to evade specialized file-based

detection techniques

• Why? The filesystem is heavily scrutinized
• Fileless Attacks is just one trend observed on this evolution
• Threats that use process manipulation and built-in scripting mechanisms rather than dropping

executable files

• Use of built-in tools allows malware to blend in as legitimate
• It is common for them to run completely in memory (memory resident malware)
• Many attack vectors (Registry, WMI, scripting languages, STs, GPOs, etc.)
• They are often the first stage of a multi stage attack
• Harder to investigate in retrospect

Problem Description

5 Source: BRK3116 – Microsoft Ignite Conference

Fileless Attack Ontology

No file activity is performed

Type I

Only “indirect“ file activity involved

Type II

The threat has a fileless persistence or presence on the machine, but requires files to

• perate

Type III

HARDWARE MBR CPU PCI FILE NETWORK CODE INJECTION MACRO FILE JS VBS PS Remote Attacker Documents LNK Sch Task Exe Service Registry WMI Repo Shell Network Card Hard Disk Circuitry backdoors, IME Disk partition Java Flash Exe USB BadUSB VM Hypervisor BIOS UEFI Mobo Firmware

Multiple Techniques

6

Fileless Attacks Detection Approaches: What works

Type I: No File Activity Memory Scanning Can catch injected modules or payloads or shell codes Behavior Monitoring Suspicious/anomalous behavior used alongside

• ther signals to detect

threat activity Type II: Indirect file activity Behavior Monitoring Catches installation & persistence not relying on files (WMI, autorun keys, etc) Trust level Protection It detects trusted processes suspicious activity AMSI Catches scripting activity even when highly

• bfuscated

Type III: Files required to Operate Memory Scanning It catches injected payloads or scripts loading .NET binary directly from memory. Behavior Monitoring Suspicious behaviors from common Macro or scripts can be caught AMSI Catches scripting activity even when highly

• bfuscated

ML in the client and cloud to scale these protections against new and emerging threats

Source: BRK3116 – Microsoft Ignite Conference

7

• OpenProcess - Grab handle to target process
• VirtualAllocEx - Allocate a new chunk of

memory in target

• WriteProcessMemory - Write the

shellcode/payload into target

• CreateRemoteThread - Start a new thread to

execute the payload Classic DLL Injection

Example of Code Injection Techniques

Poison Ivy

8

• DLL that maps itself into memory - original

design and code by Steven Fewer

• Handy from attacker perspective - makes for

a ‘dumb’ injector. Available in github

• No longer have to code in assembly
• Very common technique (ex: meterpreter,

powershell empire)

• Allocate memory, map sections, resolve

imports, fixup relocations, call entry Reflective DLL Injection

Example of Code Injection Techniques (contd)

Meterpreter Payload

Source: SANS_Hunting_In_Memory – Joe Desimone

9

• Create new, suspended process
• Allocate new memory, unmap (hollow)

existing code

• Write payload
• Redirect execution - SetThreadContext() and

ResumeThread()

• Stealthy variants
• Create/Map sections to avoid

WriteProcessMemory

• Modify entry point instead of

SetThreadContext Process Hollowing

Example of Code Injection Techniques (contd)

DarkComet Payload

Source: SANS_Hunting_In_Memory – Joe Desimone

10

Challenges with detection through memory scanning

Threat Hunters rely on personal knowledge and intuition to digest enterprise data and detect problems Threat Hunters expertise is critical and needs to be up- to-date to cope with latest threats On-going attacks are hard to detect on the complex and constantly changing Enterprise Memory resident malware has become increasingly sophisticated

Threat Hunters need an automated way to detect memory resident malware at scale

11

Introducing Memhunter

Memhunter automate the hunting of memory resident malware at scale, improving the threat hunter analysis process and remediation times Memhunter in a nutshell

• It is an standalone binary that gets itself deployed as a windows service
• It uses a set of memory inspection heuristics and ETW data collection to

find footprints left by common injection techniques.

• Forensic information on findings gets reported through console or event

logs for forwarding

https://github.com/marcosd4h/memhunter

12

Memhunter Architecture

13

Memhunter hunting process

Deployment Start Collection Hunting orchestration

• ETW data collection correlation
• Suspicious events trigger heuristic

plugins

• Report creation based on findings

14

Current functionalities

• 9 hunter heuristics included (see next slide)
• 15 code injection techniques implemented on minjector test tool
• ETW data collection of suspicious events used for heuristic

triggering

• Windows Event Log generation
• Exclusion of baseline detection
• Basic forensic information
• Sqlite storage integration

15

ETW Suspicious Events

• Process Creations (Microsoft-Windows-Kernel-Process)
• Registry Operations (Registry operations at Microsoft-Windows-Kernel-Registry and

AE53722E-C863-11d2-8659-00C04FA321A1

• Threads Operations (thread kernel provider at 3d6fa8d1-fe05-11d0-9dda-

00c04fd7ba7c)

• Virtual Alloc Operations (Page Fault Provider at 3d6fa8d3-fe05-11d0-9dda-

00c04fd7ba7c)

• Image Load Operations (Image load provider at 2cb15d1d-5fc1-11d2-abe1-

00a0c911f518)

• Kernel Audit APIs usage (Microsoft-Windows-Kernel-Audit-API-Calls)
• Future usage - Only on win10 - Suspicious APIs via Microsoft-Windows-Threat-

Intelligence

16

Hunters (Hunting Heuristics)

• Suspicious Modules (status: implemented)
• Look for Modules that are associated with RWX memory regions
• Suspicious Threads (status: implemented)
• Inspect memory regions associated with threads looking for RWX flags, starting with

memory regions associated to thread base address

• Unbacked or Floating code living in the memory regions of the process
• Suspicious Memory regions (status: implemented)
• Inspect memory regions of the entire process looking for RWX flags
• Check PE header over these regions (fuzzy PE match)

17

Hunters (Hunting Heuristics) (contd)

• Suspicious Call stack (status: implemented)
• Check call stack of threads looking for unbacked symbols (floating code)
• Suspicious Base Address (status: implemented)
• Base Address of main module (.exe) is private: commit and marked as RWX (should never

happen, it should be memory mapped always. Detects Process Hollowing

• Suspicious Exports (status: implemented)
• Look for exports like “ReflectiveLoader()” on the list of modules/exe exports

18

Hunters (Hunting Heuristics) (contd)

• Suspicious hollowed modules (status: implemented)
• In-memory vs on-disk comparison
• Comparing linker version, entry points, size of code (PE header). LDR vs PEB.
• Suspicious Registry Persistence (status: implemented)
• It looks for common registry injection/persistence techniques such as IFEO (Image File

Execution Options), Appinit_DLL and AppCertDLLs

• Suspicious Shellcodes (status: implemented)
• It looks for RXW memory regions that starts well known x86 or x64 prologues opcodes

19

Hunters (Hunting Heuristics) (contd)

• Suspicious PEB modification (status: code being tested - not pushed)
• PEB Unlinking. It looks for hidden DLLs modules. It compares what is reporting by win32

APIs with what can be obtained from the kernel (kernel call through EPROCESS)

• Suspicious CLR Reflection (status: code being tested - not pushed)
• It detects .NET loaded serialization (System.Reflection.Assembly.Load(byte[]).
• It looks for CLR module loaded without file backing. Memory regions associated is

MEM_MAPPED, RW and MZ/PE at address.

• Suspicious Spoofing (status: code being tested - not pushed)
• It cross check process cmdline from PEB with cmdline from ETW kernel provider to look for

signs of cmdline spoofing

• It cross check process parent PID from NtQuerySystemInformation with process genealogy
• btained from ETW kernel provider to look for signs of parent pid spoofing

20

Forensic information

• Suspicious PID
• Suspicious TID
• Thread integrity levels
• Abnormal user tokens
• SE Debug privileges. Debug Token
• Integrity levels
• EoP tokens
• Unique Thread token
• Thread BASE Priority (Thread have more priority than other threads)
• Token Integrity level, Enabled Privileges, SID/Username, Logon Session, Logon Type,

Authentication Package used, etc

• Group SID

21

Demo Time

22

Questions? Thanks!