Hotpatch Mechanism for Stealthy User-Mode Process Injection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing methods for security exploits to create user-mode processes or threads are cumbersome and detectable, particularly when trying to avoid writing components to disk, as they require substantial programming effort and can be detected by security software.

Innovation Solution

The use of a hotpatch mechanism to modify a component loader, allowing it to request execute rights for a section object associated with a user-mode component, enabling the creation of a user-mode process, thread, or held reference without writing to disk, by initially creating a page file-backed section object with read/write rights and then invoking the hotpatch mechanism to modify the component loader and set an entrypoint for execution.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If an exploit writes a DLL to disk and causes a user-mode process to load the DLL, then the exploit can create user-mode processes or threads, but such writes to disk may be detected by security software

Engineering Contradiction:
Improvestealth of exploit executionVSAvoidcomplexity of exploit implementation
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The exploit extracts the DLL from disk storage and loads it directly into memory space, eliminating the need for disk writes that would be detected by security software. The DLL is injected into the target process's address space and executed from memory only.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The exploit uses an intermediary process or mechanism to load and execute the DLL without direct disk access. By leveraging the operating system's loader and process injection capabilities, the exploit transfers the DLL through memory as an intermediary state between creation and execution.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If an exploit includes a dynamic-link library and coerces or tricks a user-mode process into loading the DLL, then the exploit can operate in user-mode, but this requires substantial programming effort

Engineering Contradiction:
Improvefreedom of action in user-modeVSAvoidprogramming effort required
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The exploit leverages the operating system's own loading and execution mechanisms to perform the work of DLL injection automatically. By using standard OS APIs and process injection functions, the exploit avoids complex custom loading code while still achieving user-mode operation.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The exploit uses universal process injection techniques that work across different user-mode processes without requiring process-specific customization. The same DLL injection mechanism can be applied to any target process that supports the injection method.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Productivity

If an exploit uses existing process injection mechanisms, then the exploit can run code in the context of an existing process, but these mechanisms have difficulties and can be detected

Engineering Contradiction:
Improveefficiency of process creationVSAvoiddetectability by security software
Core Design Contradiction:
ProductivityVSDifficulty of detecting and measuring

Solution Approach 1:

The exploit modifies specific local characteristics of the DLL loading process, such as memory protection attributes and section flags, to make the injected DLL appear legitimate to security software while maintaining executable functionality.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

Instead of having the target process load the DLL normally through standard loading mechanisms, the exploit inverts the approach by directly injecting the DLL into the process's memory space and forcing execution, bypassing the usual loading detection points.

Inventive Principle:
Principle #13The other way round (Inversion)

Data Source

PatentEP2987111B1Executable component injection utilizing hotpatch mechanisms
Publication Date: 2020.01.15 CROWDSTRIKE
  • EP2987111B1 patent drawingFigure 1
  • EP2987111B1 patent drawingFigure 2
  • EP2987111B1 patent drawingFigure 3

AI summary

Techniques for causing a component loader associated with a hotpatch mechanism to execute a user-mode component which, when executed, creates a user-mode process, thread, or held reference are described herein. The component may further indicate to the component loader that it lacks hotpatch data, causing the component loader to unload the component. In some implementations, a kernel-mode module may initially provide the component to the hotpatch mechanism with an entrypoint of the component set to zero and with hotpatch data for the component loader. The hotpatch mechanism may apply the hotpatch data, modifying the component loader such that the component loader requests execute rights for a section object for the component. The kernel-mode module may then set the entrypoint such that the component becomes executable, and provides the section object and component to the hotpatch mechanism to cause the component loader to execute the component.