Nighthawk 0.2.1 - Haunting Blue - MDSec (2024)

ActiveBreach

November 1st 2022

This Halloween week brings our third and final Nighthawk release for the year and its packed with exciting new features, backed by MDSec’s world class research and development team. Indeed, there are so many new features that move the needle, this release could easily have been a major release. However, as it will be our last release in the current architecture (watch this space! :coolbemused:) we decided to issue it as a minor version. But let that take nothing away from the exciting new features it includes, many of which are first time to any public framework. Without further ado, let’s dive in to what’s new.

To date, Nighthawk has always been stageless; that is, the artifacts exported from the framework contained a full copy of the beacon. While we did introduce the concept of keying in 0.2, this release takes things one step further by offering a stager. The stager can be useful in a number of scenarios, and particularly when performing initial access or persistence as it allows the operator to send only a small portion of shellcode to the user without the risk of immediately exposing the full beacon.

0.2.1 provides a new payload generator within the UI, allowing the operator to export ~20kb of customisable shellcode that will retrieve an image over HTTP(S) and extract the Nighthawk stageless shellcode from it, then load it in process. Not only this, the stego stager also offers all the benefits of Nighthawk’s opsec, including the use of indirect syscalls, unhooking and other evasive features:

For input, the payload generator will accept any shellcode and lossless image format, using steganography to hide the shellcode inside the modified image.

When combined with Nighthawk’s other payload generation features, such as keying, it allows the full execution chain to offer a high degree of protection for the beacon artifacts; a methodology for execution may look as follows:

To illustrate the stager, the following video shows creation of 24kb of shellcode that performs a variety of OpSec magic, it then retrieves a PNG image via HTTP that Nighthawk has created and uses steganography to extract the shellcode and load it in process:

In June 2021 we released a blog post on “Bypassing Image Load Kernel Callbacks” with a companion proof of concept tool called “Dark Load Library” from our colleague @_batsec_. This research illustrated how manual mapping could be used to bypass telemetry associated with image load events. Conceptually, this technique is powerful as it can assist in avoiding signatures backed by these indicators which have plagued other frameworks as we illustrated in other research.

For example, to detect the use of mimikatz in an environment a threat hunter might simply hunt for all image load events that occurred within a short period of time and matched a signature of dlls loaded by the tool such as vaultcli.dll, cryptdll.dll and samlib.dll. See this example provided by Splunk for more practical detections. Other examples might include anomalous loading of the CLR and associated DLLs being used to hunt for .NET post exploitation activities.

Nighthawk 0.2.1 brings the integration of a fully weaponised implementation of Dark Loading, allowing all Nighthawk dependencies to be manually mapped in to memory of the host process. These DLLs can then held in an encrypted state at rest and removed from the PEB and other sources used by the loader such hashlinks. The Nighthawk dark loader is available not only for all Nighthawk threads, but also process wide if required. Consequently, this means Nighthawk is able to dark load all DLL dependencies used by post-exploitation tooling, including the inproc-execute-assembly CLR harness and the execute-exe PE harness. That is, running any .NET assembly or any PE binary in a unique thread inside the beaconing process will not trigger any image load events, nor will the DLL be immediately visible by tools that attempt to list the modules of a process.

Let’s take a look at this in action:

In this video, we see Nighthawk injected in to a remote process and then subsequently used to execute a .NET assembly in a thread of that process. While monitoring the process for image load events using procmon and Sysmon, we see no image load events (ID 7), we also see Nighthawk manually map the DLL dependencies to the process, monitoring this in Process Hacker we see they are linked in the PEB then subsequently unlinked where they are held in encrypted in virtual memory on sleep.

Sometimes during a red team engagement, the operator may find themselves needing to run a thick client application from within the environment to achieve their operation objectives. Common examples include database clients, financial applications or MFA soft token software. Typically, this software is accessed using SOCKs proxy to remote desktop, or over an injected remote VNC channel. Both of these approaches have various drawbacks, with the injected reverse VNC channel being often signature rich and has the limitation that the real user can witness any changes to the desktop.

With this release Nighthawk brings a fully interactive, hidden desktop. This implementation does not use any VNC like protocol, and instead relies on a completely custom implementation of a virtual desktop built using legitimate Windows APIs that are frequently used by legitimate software such as Chrome. The Nighthawk implementation will take screenshots of the virtual desktop and adjust them inline with the operator’s desired image quality, extracting them over the c2 channel and aligning to the sleep time and using configurable chunk sizes. Keystrokes and mouse movements are then translated from the operator’s view, to the hidden desktop, allowing the operator to fully control thick client applications on the virtual desktop. All interaction on the hidden desktop is completely transparent to the user; applications will not be visible on the taskbar nor will GUI applications appear in view.

A video demonstration of the hidden desktop can be seen below:

As can be seen in the video, we’re able to open desktop applications such as Chrome (inheriting the user’s cookies), command prompt, file explorers etc and this remains transparent to the user using the desktop.

Nighthawk has provided a safe environment for executing both the CLR and COFF binaries in our .NET and BOF harnesses since release. However, this does not account for all possible tool formats that the operator might want to run. This release brings a custom PE loader to Nighthawk, allowing the operator to execute most PE binaries on the remote host, in-process and within its own thread. Furthermore, any PEs executed using the execute-exe command will also benefit from the OpSec configuration of Nighthawk’s Dark Load Library, meaning that any dependencies used by the PE will be manually mapped and hidden in memory.

The execute-exe PE loader can be used to run the majority of your favourite tools such as mimikatz, the Sysinternals suite or make living off the land great again by running native Windows binaries without any process creation events. The binaries are read from the operator’s machine, communicated over the c2 channel and executed in-process, never touching disk; once execution is complete the PE is wiped from memory. Not only this, but the PE loader supports GUI based applications providing they’re sufficiently portable, allowing them to be executed on the hidden desktop without being seen by the user.

Let’s take a look at Execute-Exe in action:

In this video, we demonstrate running mimikatz.exe from the operator’s machine, being transferred over the c2 channel and run in a thread inside notepad.exe. When combined with our dark loading capabilities, there are no image load or process creation events and the exe is removed from memory following execution.

In the second part of the video, we show a Nighthawk beacon running on a hidden desktop session inside chrome.exe; the video shows how we are able to load even GUI based applications (assume portable) from the operators machine, in the chrome.exe beacon process, and controllable from the hidden desktop. These remain invisible to the user and also benefit from the dark loading capabilities.

The use of .NET for post-exploitation has grown significantly over the past few years, with many of a red teamer’s favourite tools being developed in the language. This of course led to increased focus on .NET tradecraft from defenders. While we won’t dive in to how these detection opportunities are frequently implemented (we hope this will follow in a future post!), it is sufficient to say that many EDR products have the capability to accurately detect .NET post-exploitation outside of the traditional EtW based detections by monitoring for floating modules being loaded.

To provide continued evasion against such detections, this release of Nighthawk now offers the ability to perform module stomping of .NET assemblies for both our in-process CLR harness, and our custom c2 channels. When using .NET stomping, Nighthawk will load a legitimate module from the global assembly cache and overwrite it with the contents of the assembly provided by the operator. The on-disk module will remain with its legitimate metadata in the PEB and will otherwise appear as though it’s been legitimately loaded by the process with the exception that the assembly that has been executed is that of the operator. Indeed, even when executing an assembly that uses reflection to display its codebase through “Assembly.GetExecutingAssembly().CodeBase;”, it is shown to reference the on-disk module. This feature provides a powerful and effective means of blending .NET tradecraft and can be used in conjunction with Dark Load Library to hide the image load events associated with the CLR and avoid the modules being listed in the PEB.

Let’s take a look at what happens when we run an assembly that’s been module stomped:

In this final video, we show an injected beacon inside notepad, running a .NET assembly in process. The .NET assembly is run in place of a loaded System.Web.Mobile.dll from the global assembly cache. The .NET assembly uses reflection to execute “Assembly.GetExecutingAssembly().CodeBase;” which shows the location of the assembly module on disk.

In addition to the above big ticket features, a number of other further enhancements were made that bring additional improvements to Nighthawk, including but not limited to:

• Support for arbitrary indirect syscall execution and return address spoofing: Previously, Nighthawk supported indirect syscall execution by proxying calls through NTDLL. This release however passes control of the DLL to be proxied over to the operator through an array of substrings. This feature provides evasion for certain EDRs that expect syscall execution to originate from a specific DLL.
• Improved SOCKS support: The 0.2.1 release now includes a completely rewritten socks4a server. This includes a number of enhancements such as multi operator support through the teamserver and increased speed and performance.
• PEB spoofing for module stomping: Nighthawk has always provided a module stomping feature since release. This feature has however been enhanced with this release, allowing the operator to spoof the module name used for the backing module in the PEB. This feature provides additional evasion to EDR detections that expect certain events to occur from specific modules.

Nighthawk 0.2.1 will be made available for customer download this week, please watch out for announcements.

Hacky Halloween all! – @MDSecLabs

Stay updated with the latest
news from MDSec.