What is a Native Application?

Most Windows applications come in two “flavors”, GUI and console (command-line) applications. There are a few differences between the two, most notably the Windows Subsystem on top of which they are executed. The Subsystem can be seen by examining an executable’s PE header:

There are actually quite a few Subsystem options, but today we are going to be focusing our interest in the Native subsystem. Native Applications are PEs compiled to run against the Native Windows subsystem. Unlike the other two Subsystems you might already be familiar with, the Native one is quite bare-bones.

First of all, attempting to execute a Native Application through File Explorer (by double-clicking) or the command line yields the following error:

Our only option for executing Native Applications (aside from manually loading the binary in memory) is RtlCreateUserProcess.

Secondly, Native Applications can only depend on ntdll.lib, the static version of ntdll.dll. This is quite an important limitation, since there is also no possibility of dynamically importing libraries. Essentially, we have to stick to NTDLL exports. This happens because applications targeting the Native subsystem are generally expected to be executed early on in the userland bootstrap sequence, where other subsystems might not have been (fully) initialized.

Why develop a Native Application?

An interesting, but relatively undocumented execution mechanism in Windows resides in smss.exe, the Windows Session Manager. Session Manager, among other things, provides the functionality of auto-starting applications during the initialization of the user session. An example of an intended use case is filesystem verification, which happens by having smss.exe spawn autochk.exe during the “Welcome” logon screen.

This mechanism utilizes the following registry hive:

Notice the BootExecute multi-string entry which reads:

autocheck autochk *

This is the entry which triggers autochk.exe and passes it the argument “*”, the command that smss.exe executes at the “Welcome” screen. Notice how only the executable name is mentioned, not the extension or the full path. This is because in order for a Native Application to be executed by smss.exe through BootExecute, it needs to be located in C:\Windows\System32.

The information outlined here can also be found in this blog post by Protexity. Digging a little deeper though, I uncovered some interesting insights on the inner workings of smss.exe, the BootExecute key as well as a new registry entry that functions similar to BootExecute, the BootExecuteNoPnpSync key.

Why target smss.exe?

Native Applications executed by smss.exe through BootExecute do so under the context of NT Authority\SYSTEM, with a plethora of granted privileges and very early in the usermode initialization, before the userland components of EDR solutions are initialized. As a result, there are quite a few offensive opportunities to this implementation, provided that we have:

• a way to remotely edit the HKLM registry hive of a host
• a way to plant a binary to \??\C:\Windows\System32 on the target host.

From an offensive-security standpoint, it was decided to focus on opening process and thread handles using the NT Authority\SYSTEM process token as a POC.

Evitan – The Native Application backdoor

Building Native Applications with Visual Studio requires a couple of configuration steps. Stack cookies have to be disabled (/GS-) and intrinsics are a good idea (/Oi). As far as linking is concerned, the Native Application must be linked ONLY against ntdll.lib and the Subsystem has to be set to Native.

Finally, the Native Application does not begin its execution at int main(), but rather at void NTAPI NtProcessStartup(PPEB peb).

After writing a quick hello-world Native Application to test and verify the project skeleton, I decided on this main loop for the backdoor:

• Begin execution
• Create a synchronization event
• Allocate some shared memory for communication
• Wait until the event is set by the client process
• Read the shared memory to identify the client process ID and command
• Get a handle to the client process
• Execute the commands and duplicate any resulting handles to the client process
• Go to step 4

I then borrowed Pavel’s implementation of NativeRun and incorporated it into the project, to allow testing Native Applications without going through smss.exe.

Fleshing out the above main loop looks a bit like the following:

On the client side, an application that requests elevation from the backdoor looks like this:

Too good to be true…

The issue

Although through NativeRun both the backdoor and the client operated as expected, when spawned through smss.exe the backdoor resulted in hanging the “Welcome” screen. This was an immediate road block, since another limitation was added to the list; Native Apps executed through BootExecute need to terminate their execution for smss.exe to continue its operations. Or… Do they really?

I decided to break out Ghidra and start looking around at the inner workings of smss.exe. During its setup stages it reads the BootExecute key, along with other relevant information from the registry and then proceeds to call SmpExecuteCommand for each member in the SmpBootExecuteList:

SmpExecuteCommand calls SmpParseCommandLine and then passes the result to SmpExecuteImage:

SmpExecuteImage is responsible for executing a Native Application and holds the root cause of our issue, a WaitForSingleObject call that expects our process to terminate:

Luckily enough, our problem lies within a branch, controlled by some flags:

By reversing SmpParseCommandLine we find more information on the supported flags. As it turns out, the following flags are supported:

• BOOTEXECUTE_ASYNC
• BOOTEXECUTE_SECURE
• BOOTEXECUTE_DEBUG
• BOOTEXECUTE_AUTOCHECK

They are set by comparing the first token of each command (remember the syntax?) to some predefined values which are:

• async (Executes a Native Application without waiting for it to terminate)
• secure
• debug (The execution attempt is logged but the application is not actually spawned)
• autocheck (Bingo, our magic string!)

The data references look as follows:

And finally…

Proof of Concept

After a quick modification of the BootExecute key, dropping the backdoor to \??\C:\Windows\System32\Evitan.exe and a quick reboot,

we can execute EvitanClient.exe, the POC client application that will request elevated actions, in this case terminating a system process:

The complete project files accompanying this blog post can be found at the HackCraft Github.

Why not use token impersonation?

When Evitan was initially fleshed out, its goal was taking advantage of SE_DEBUG_PRIVILEGE and SE_TCB_PRIVILEGE to open a handle to the backdoor client process, receive a target thread handle and duplicate the handle to its own process using the acquired backdoor client process thread handle. Soon after it would duplicate its process token the same way and set it to the impersonation token for the targeted thread. The problem with this approach is that duplicating token handles across session boundaries is unsupported and as a result, the idea of transferring privileges through the token was dropped in favor of transferring privileged resources by handle duplication.

Features

The final version of Evitan shared along with this blog post contains the following list of features:

• Elevated Process / Thread Termination
• Token Session ID Swapping
• Process Memory Dumping

More features/commands can be added easily, as required.

Disclaimer

This blog post and the accompanying project files are provided only as a POC and are not expected to be production-grade, bug-free code. Please take this into consideration before utilizing Evitan.

References

• Pavel’s NativeApps
• Pavel’s SECArmy Village Grayhat 2020 Presentation
• Protexity’s Going Native Blog Post

Intro

As discussed in our previous post, regarding Fairplay, during Red Team engagements a lot of focus is shifted into preserving and protecting the malware. Fairplay does its fair share of work to provide us with the information on when we get detected, but before that, we needed a way to make sure that each and every single payload that we utilize is unique. This ultimately prevents mass-actions taken against static information in our payloads, since each payload is always unique statically and perhaps even sometimes behaviourally.

However, not all payloads are the same. Red Teams usually assess and evaluate multiple potential entrypoints, each one with its own caveats. There are vast differences between platforms, technological stacks and contexts. There are for example native Windows executables, managed .NET assemblies, VBScript/JScript HTA or CHM enabled documents, etc. The plethora of possible combinations of attack chains and scenarios is huge when the potential options are served with a multitude of different attack chains, comprised of sets of TTPs. The previous example now becomes:

• Native Windows Service Executable that performs self injection of shellcode using RtlRunOnceExecuteOnce
• .NET executable that performs AppDomainManager hijack to remote process shellcode injection targetting Explorer.exe
• …

As one can observe, the list quickly grows out of hand rather quickly. This created a nuance from both the developers’ as well as the operators’ perspectives. It became apparent that producing unique builds that are comprised of smaller, TTP based modules, in multiple “wrapper” formats (.exe, .dll, .hta, etc.) at will without deep diving in the code required for an across the board solution that could template malware at source code level.

What is Blueprint?

Blueprint is a python3 source-code level modular templating solution based on Jinja. It is developed by the Hackcraft Red Team and is open-source and freely available.

Github repository: https://github.com/Hackcraft-Labs/Blueprint

Jinja boilerplate

Blueprint extends the classic Jinja syntax and offers modularity through the use of filters. Filters, functionality native to Jinja, are essentially python-backed functions that receive input which they operate on and return the output. They can be called in the Jinja context in the form of pipelines, which are evaluated to the final outputs. An example is as follows:

{{ "Example" | filter1 | filter2 }}

Here, the expression inside the double braces will be evaluated as the equivalent of the following python snippet:

filter2(filter1("Example"))

Example definitions of filter1 and filter2 could be as follows:

def filter1(inp):
    return inp + "1"

def filter2(inp):
    return inp + "2"

As a result the above expression would be evaluated to Example12.

Blueprint modules

Blueprint offers an extensive list of sinister modules which we use extensively in our malware, which of course can be extended in python3 and is as follows:

• Input/Output
  • Content : Retrieves the binary contents of a file
  • Output : Writes to a binary file
• Crypto
  • AES : Performs AES encryption with a randomly generated key and IV
  • XOR : Performs XOR encryption with a randomly generated single-byte key
• Hashing
  • DJB2 : Computes the DJB2 hash of the input, which is useful when hashing known strings for obfuscation
• Format
  • HexArr : Formats the input to a comma-separated array of hex represented bytes
  • DecArr : Formats the input to a comma-separated array of decimal represented bytes

The author of the template can use these modules as a language-agnostic build-time metaprogramming environment to tweak certain aspects of the code. Consider for example the following use case:

// File: example.h.tpl

// In this malware, we need to execute a piece of shellcode.
// The shellcode is AES encrypted at rest and decrypted before being self-injected at runtime.

// Let us define a C array of bytes to hold the AES encryption key.
// Notice the Blueprint templating which will evaluate to the value of the variable AES_KEY as a hex-array.
unsigned char key[] = { {{ AES_KEY | hexarr }}} ;

// Same process, but for the encryption IV this time.
unsigned char iv[] = { {{ AES_IV | hexarr } }}

// Now for the actual shellcode, let us:
// - Retrieve the contents of payload.bin 
// - Encrypt it with the aes module (Random key and IV will be generated and output to AES_KEY and AES_IV respectively)
// - Represent it as a hex-array
unsigned char payload = { {{ "payload.bin" | content | aes | hexarr }} }

Notice how this is not constrained to a certain compiler, let alone a specific language or context. This can be used in any source code file and can of course be extended at will.

Behavioral modularity

In Blueprint templates, we can also leverage Jinja control-flow primitives to offer a way to the operator to toggle certain features on or off at build time, without having to make changes to the code. Consider the following example:

// File: example.c.tpl

// Include our payload header file, produced by example.h.tpl
#include "example.h"

// ... snip ...
int __stdcall WinMain(HINSTANCE hInst, HINSTANCE hInstPrev, PSTR cmdline, int cmdshow)
{
    // Decrypt the shellcode
    perform_aes_decryption(payload, sizeof(payload), key, iv);

    // If PATCH_ETW is set, then disable it.
    {% if PATCH_ETW %}
        disable_etw();
    {% endif %}

    // Perform the injection.
    inject(payload, sizeof(payload));
}

Metaprogramming concepts

Another cool side-effect of templating is that you can provide an abstract interface to the operations team. Consider for example the use case where malware can target a list of processes to inject shellcode to, which can vary in size. Also, all these strings should be encrypted in some way to prevent static identification. This becomes as simple as:

{% for process_name in INJECT_TO_PROCESSES %}
unsigned char proc_{{ loop.index }}_str[] = { {{ process_name | xor | hexarr }} };
{% endfor %}

We just defined a number of C arrays containing the XOR encrypted versions of the process name strings defined in the python array INJECT_TO_PROCESSES.

Bringing it all together

Now all that’s left is wrapping up this hot mess of features into a neat little present before presenting the dev team’s work to the operators, which is offered through the magic of JSON configuration files. An example for our case would be as follows:

{
    "filters":[
        "crypto.AES",
        "crypto.XOR",
        "io.Content"
    ],
    "targets":[
        {
            "input":"example.h.tpl",
            "output":"example.h",
            "variables":{}
        },
        {
            "input":"example.c.tpl",
            "output":"example.c",
            "variables":{
                "INJECT_TO_PROCESSES":["explorer.exe", "TextInputHost.exe"],
                "PATCH_ETW":true
            }
        }
    ]
}

This configuration file can be editted at will by the operations team to provide malleable capabilities to each campaign and scenario, while allowing for it to morph on its own as well during each built, to provide OPSEC against static checks. It is parsed by Blueprint, in the following way:

• The filters defined are imported into the context.
• For each entry in targets:
  • The input file is evaluated as a Blueprint template.
  • The variables are inserted into the context.
  • The end result is written to the file defined in the output.

Then, your usual build pipeline continues, targetting the files output by Blueprint. Again, this supports anything from an VS/MSBuild C/C++ project to a JScript CHM Help Studio project.

That’s it, we are done! Almost…

A love letter to the devs

Blueprint abstracts away many of the nitty gritty details of the underlying malware code, but after using it for a while it was pretty aparrent that it completely broke syntax highlighting on every editor out there. Unfortunatelly, the solution to this can not be easily abstracted away, but we have created a small plugin for Visual Studio Code to facilitate authoring Blueprint malware templates, which supports syntax highlighting for Blueprint templates containing the following languages/contexts:

• C/C++
• C#
• Batch

The list can of course be further extended. May the eye-strain be reduced! 🙂

The plugin will be released in the near future, so keep an eye out!

Contributions

Contributions to the code base of Blueprint are very much welcome through Pull Requests submitted on its repository, both for the framework as well as for new modules that provide functionality related to malware development.