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

Hunting For Memory Resident Malware Memhunter tool Marcos Oviedo | McAfee Endpoint Software Architect 1

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

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) Marcos Oviedo @marcosd4h I’m going to be speaking at both Blackhat Arsenal 19 and Defcon 27 Demo Labs this year! 3

Problem Description • 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 4

Fileless Attack Ontology LNK Sch Task Documents Exe Multiple Type I Techniques Java MACRO Flash No file activity is performed FILE CODE Type II Disk FILE Exe INJECTION partition MBR Only “indirect“ file activity involved Service JS Registry Remote VBS NETWORK WMI Repo Attacker Type III PS HARDWARE The threat has a fileless Shell VM PCI CPU BIOS persistence or presence on the USB UEFI machine, but requires files to Network Card Hypervisor operate Hard Disk Circuitry Mobo backdoors, Firmware IME BadUSB Source: BRK3116 – Microsoft Ignite Conference 5

Fileless Attacks Detection Approaches: What works Type II : Indirect file Type III : Files required to Type I : No File Activity activity Operate Behavior Monitoring Memory Scanning Memory Scanning Catches installation & It catches injected Can catch injected persistence not relying on payloads or scripts loading modules or payloads or files (WMI, autorun keys, .NET binary directly from shell codes etc) memory. Behavior Monitoring Behavior Monitoring Trust level Protection Suspicious/anomalous Suspicious behaviors from It detects trusted behavior used alongside common Macro or scripts processes suspicious other signals to detect can be caught activity threat activity AMSI AMSI Catches scripting activity Catches scripting activity even when highly even when highly Source: BRK3116 – Microsoft Ignite Conference obfuscated obfuscated ML in the client and cloud to scale these protections against new and emerging threats 6

Example of Code Injection Techniques Classic DLL Injection • 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 Poison Ivy 7

Example of Code Injection Techniques (contd) Reflective DLL Injection • 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 Source: SANS_Hunting_In_Memory – Joe Desimone Meterpreter Payload 8

Example of Code Injection Techniques (contd) Process Hollowing • 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 DarkComet Payload Source: SANS_Hunting_In_Memory – Joe Desimone 9

Challenges with detection through memory scanning Memory resident malware On-going attacks are hard Threat Hunters rely on Threat Hunters expertise is has become increasingly to detect on the complex personal knowledge and critical and needs to be up- and constantly changing intuition to digest to-date to cope with latest sophisticated enterprise data and Enterprise threats detect problems Threat Hunters need an automated way to detect memory resident malware at scale 10

Introducing Memhunter Memhunter automate the hunting of memory resident malware at scale, improving the threat hunter analysis process and remediation times https://github.com/marcosd4h/memhunter 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 11

Memhunter Architecture 12

Memhunter hunting process Hunting orchestration • ETW data collection correlation Deployment Start Collection • Suspicious events trigger heuristic plugins • Report creation based on findings 13

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 14

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 15

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) 16

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 17

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 18

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 obtained from ETW kernel provider to look for signs of parent pid spoofing 19

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 20

Demo Time 21

Questions? Thanks! 22