Home Malware Analysis Projects About

Fennec is my messing-around-with-edr-stuff project. The goal is to implement a bunch of different detection capabilities to better understand their internals. So far, this consists of a Time/Event Based Memory Sweeper, an EtwTi Agent, and an orchestration process which receives events from these processes and passes them off to the ELK Stack, whilst also showing the user a Windows Toast Notification. On the agenda there is more EtwTi, a Hooking DLL, and probably some other stuff.

Table of Contents

Key Features

Demo

Event Tracing for Windows Threat Intelligence (EtwTi) Agent

A core component of this project going ahead will be Event Tracing for Windows Threat Intelligence. I had a hard time finding a good reference for just the topic, this was the closest I got: Microsoft-Windows-Threat-Intelligence.xml. It is an XML manifest containing all the available data from EtwTi. Imagine traditional ETW, but for malicious activity...

Using Krabs ETW as the library, and PPL Runner to give access to a PPL Process, a proof-of-concept was created which identified Process Injection. As time goes on, this can be expanded for function patching, LDAP Queries, etc. For now, here is the potential EtwTi types:

case KERNEL_THREATINT_TASK_ALLOCVM_REMOTE:
case KERNEL_THREATINT_TASK_PROTECTVM_REMOTE:
case KERNEL_THREATINT_TASK_MAPVIEW_REMOTE:
case KERNEL_THREATINT_TASK_QUEUEUSERAPC_REMOTE:
case KERNEL_THREATINT_TASK_SETTHREADCONTEXT_REMOTE:
case KERNEL_THREATINT_TASK_ALLOCVM_LOCAL:
case KERNEL_THREATINT_TASK_PROTECTVM_LOCAL:
case KERNEL_THREATINT_TASK_MAPVIEW_LOCAL:
case KERNEL_THREATINT_TASK_QUEUEUSERAPC_LOCAL:
case KERNEL_THREATINT_TASK_SETTHREADCONTEXT_LOCAL:
case KERNEL_THREATINT_TASK_READVM_LOCAL:
case KERNEL_THREATINT_TASK_WRITEVM_LOCAL:
case KERNEL_THREATINT_TASK_READVM_REMOTE:
case KERNEL_THREATINT_TASK_WRITEVM_REMOTE:

Its quite obvious what these can be used for, but for now, KERNEL_THREATINT_TASK_ALLOCVM_REMOTE was used to detect Process Injection.

Once malicious activity is detected, a json object is created and sent through a Named Pipe to the Orchestrator. From there, it is then logged to the user via a Toast, as well as sent to the ELK Server:

The full log:

{
  "data": {
    "allocation": "0x3000",
    "protectType": "0xfd190000",
    "protection": "0x40",
    "regionsize": "262656",
    "source_name": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
    "source_pid": "1712",
    "target_name": "C:\\Windows\\System32\\rundll32.exe",
    "target_pid": "3732"
  },
  "id": "3003f302-7f3b-4905-9e95-41ea7a525fd1",
  "reason": "Malicious Activity Detected",
  "task": "EtwTi Process Injection",
  "time": "Tue Mar 22 14:46:29 2022"
}

Here, it can be seen that 1712, PowerShell.exe, injected into 3732, rundll32.exe.

This wouldnt have been possible without the following:

Process Sweeps

There are, currently, two methods of triggering a Memory Sweep of all Processes:

Checking for various IOCs, and if any IOCs is found, all regions are scanned with Yara.

The following image shows the log in ELK:

Windows Toast Alert

When something happens, a log is sent to ELK. Also, the user sees a toast: