Attack Technique: Abuse of the UWP lifecycle and Windows job objects
Research by: Ogulcan Ugur (Cyber Security Analyst)
Attackers are increasingly using sophisticated methods to bypass modern endpoint detection and response (EDR) systems. One such technique involves misusing the application lifecycle of Universal Windows Platform (UWP) applications, combined with Windows job objects, for targeted attacks.
This article examines an alternative method of deliberately suspending processes early on to enable attack techniques, such as asynchronous procedure call (APC) injection or thread hijacking. Note that this technique relies on undocumented APIs and may not be supported in future Microsoft updates. Manipulating processes in a frozen state and delaying their execution until later user interaction is particularly effective. In many offensive scenarios, processes are created in a suspended state, manipulated, and then executed.
There are two common techniques that make use of this approach:
- Early-Bird Injection
- Thread Hijacking
Early-Bird Injection
In early-bird injection, the target process starts in a suspended state. This can be done using the CREATE_SUSPENDED or DEBUG_PROCESS flags, for example. This allows the attacker to manipulate the process before its regular execution begins.
Thread Hijacking
Unlike early-bird injection, thread hijacking does not initiate a new process. Rather, the attacker takes control of an existing thread within a legitimate process. First, the thread is paused with SuspendThread so that targeted preparations can be made. Then, the instruction pointer is manipulated using the Windows API SetThreadContext. Once the thread is resumed with ResumeThread, it executes the previously injected, manipulated code.
What are Universal Windows Platform (UWP) applications?
The Universal Windows Platform (UWP) is a modern application model in Windows that was introduced with Windows 8 and developed further in Windows 10. UWP applications, formerly known as modern, metro, or immersive apps, are based on Windows Runtime (WinRT) and follow a cross-platform architectural approach. The goal is to enable applications to run uniformly on various devices, including desktop PCs, tablets, Xbox, HoloLens, and IoT systems.
A key feature of UWP apps is their strong isolation within a sandbox called an AppContainer. Technically, UWP applications access a subset of COM, Win32, and WinRT APIs. Execution is subject to strict guidelines, especially regarding resource consumption and lifecycle management. For instance, a UWP application automatically enters a suspended state when it is not playing an active role in the background. This mechanism was originally developed to conserve energy.
Each UWP application has a unique package identity consisting of components such as name, version, architecture, and publisher. In short, UWP applications are Microsoft's standardized app model with a focus on security, a declarative structure, and cross-device execution.
The process lifecycle of UWP applications and its significance to attackers
UWP applications follow a clearly defined lifecycle modeled on the resource-saving app model of mobile operating systems.
After they are started, such applications typically go through four states:
- Running
- Suspending
- SuspendComplete
- Suspended
The system can perform this suspension automatically or via APIs, such as NtSetInformationJobObject, which uses the JobObjectFreezeInformation class internally.
When a process is assigned to a job object, all processes contained within it can be controlled and frozen together. Although this mechanism is intended for legitimate resource management scenarios, it offers new attack vectors in this context.
Job-Objects
Job objects are internal kernel objects used by Windows to group and collectively control processes. They allow policies, such as work set sizes, priorities, and runtime restrictions, to be applied to an entire group of processes at once.
The ability to freeze all associated processes simultaneously using NtSetInformationJobObject is particularly interesting for the attack technique described here because it allows for a kind of controlled “freezing of the environment.” Combined with UWP applications, which work with suspend/resume mechanisms by default, this creates an effective scenario for injection techniques, such as early bird injection.
Zero2504 presented a proof of concept under the title “Early Cryo Bird Injection” (https://github.com/zero2504/Early-Cryo-Bird-Injections). In this process, a job object is first created and then frozen using the corresponding information class via the NtAPI. Then, a new process is created, during which a handle to the previously created job object is provided using extended STARTUPINFOEX structures. This process automatically becomes part of the frozen job and initially remains inactive. While in this state, memory can be allocated specifically within the process, malicious code can be injected, and the process can be executed through controlled thawing.
Control frozen processes using the native NtAPI.
The targeted control of processes in this attack technique relies on the use of native Windows kernel APIs, or NtAPIs. Three functions can be used to freeze or reactivate processes via job objects.
NtSetInformationJobObject
This function uses the JobObjectFreezeInformation class to suspend an existing job object and all associated processes. The system freezes the entire process group, stopping all threads contained within it.
PsFreezeProcess / PsThawProcess
An additional control was introduced at the kernel level with Windows 10 (and continued in Windows 11): The PsFreezeProcess and PsThawProcess functions allow processes to be frozen and thawed at the thread level, regardless of their resume state. The introduction of a freeze counter is particularly important here. A process can be frozen multiple times in succession, but it will only be released for execution when the number of thaw calls completely offsets the number of freeze calls.
Another security-related effect is that a newly created thread will not be executed automatically when NtResumeProcess is called if the associated process is still frozen. This enables attackers to keep prepared processes "on hold" until a trigger point is reached, such as user interaction with a UWP interface (e.g SearchApp.exe).
Detecting Frozen Processes Using Windows Internal Structures
The PROCESS_EXTENDED_BASIC_INFORMATION structure is an important component for detecting the current status of a process. This structure contains additional information about the status of a process beyond the usual basic information.
Particularly relevant to our analysis is the IsFrozen bit in the flag field of this structure. This bit clearly indicates whether a process is currently frozen. The following sample code demonstrates how to query this status:
UWP system processes as a starting point: Misuse of SearchApp.exe and SystemSettings.exe
One interesting aspect of this attack method is the ability to exploit existing UWP system processes, such as SearchApp.exe (Windows 10), SearchHost.exe (Windows 11), and SystemSettings.exe. These processes run on almost every Windows system by default as part of the boot process, but they usually remain frozen until user interaction occurs.
An attacker can exploit this situation by inserting a new process into the same job object as the target process. When the user opens the Start menu or accesses the system settings, for example, the job object is automatically thawed by the operating system. This causes all processes within the job object, including the manipulated process, to execute.
This technique is even more effective in the case of SystemSettings.exe. Unlike the aforementioned processes, SystemSettings.exe is not an AppContainer process. Therefore, it has fewer restrictions regarding resource and API access. Tests revealed that, even when the process is suspended, it is reactivated by the user via a ShellExecute call.
API-Call Workflow
All the important steps are listed and illustrated in a diagram here:
- Creating a new job
- Assign the UWP target process to the new job
- Check to see if the UWP process is frozen
- Create a new process within the same job
- Reserve memory in the target process
- Store the DLL path or the shellcode in the reserved memory
- Queuing an asynchronous procedure call (APC), thread hijacking, or creating a new thread
- Enable injection either through user interaction or via the ShellExecute API.
Creating a new job
Assign UWP target process to the new job
Create a new process within the same job
Conclusion
We tested the most popular, top-tier EDR solutions against this technique and found that most were unable to detect the attack. One of the leading platforms was an exception, it was able to identify the attack using the “Hollowing_Inject” rule.
Our detection rules are designed to reliably identify this technique. Although there are currently no clear Sysmon events for job objects, our set of rules covers a wide range of indicators. This allows us to detect even complex attacks reliably.
This blog post demonstrates how attackers can use complex approaches to apply tried-and-true methods in new ways.
Sources
[1] Russinovich, M. E., Solomon, D. A. & Ionescu, A. (2016). Windows Internals, Part 1 & 2 (7. Aufl.). Microsoft Press.
[2] Zero2504. (2024). Early-Cryo-Bird-Injections [GitHub-Repository]. github.com/zero2504/Early-Cryo-Bird-Injections
[3] ntdoc.m417z.com. Windows Native API Documentation. ntdoc.m417z.com
[4] Microsoft Docs. Job Objects.
https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects
[5] iRED Team. Early-Bird (APC-Queue) Code Injection.
https://www.ired.team/offensive-security/code-injection-process-injection/early-bird-apc-queue-code-injection
[6] iRED Team. Injecting to Remote Process via Thread Hijacking.
https://www.ired.team/offensive-security/code-injection-process-injection/injecting-to-remote-process-via-thread-hijacking