# Nighthawk: An Up-and-Coming Pentest Tool Likely to Gain Threat Actor Notice **[proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice](https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice)** November 18, 2022 ----- [Blog](https://www.proofpoint.com/us/blog) [Threat Insight](https://www.proofpoint.com/us/blog/threat-insight) Nighthawk: An Up-and-Coming Pentest Tool Likely to Gain Threat Actor Notice ----- November 22, 2022 Alexander Rausch and the Proofpoint Threat Research Team ## Key Takeaways Nighthawk is an advanced C2 framework intended for red team operations through commercial licensing. Proofpoint researchers observed initial use of the framework in September 2022 by a likely red team. We have seen no indications at this time that leaked versions of Nighthawk are being used by attributed threat actors in the wild. The tool has a robust list of configurable evasion techniques that are referenced as “opsec” functions throughout its code. Proofpoint researchers expect Nighthawk will show up in threat actor campaigns as the tool becomes more widely recognized or as threat actors search for new, more capable tools to use against targets. ## Overview In September 2022, Proofpoint researchers identified initial delivery of a penetration testing [framework called Nighthawk. Launched in late 2021 by MDSec, Nighthawk is similar to other](https://www.mdsec.co.uk/nighthawk/) frameworks such as [Brute Ratel and](https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/) [Cobalt Strike and, like those, could see rapid adoption](https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware) by threat actors wanting to diversify their methods and add a relatively unknown framework to their arsenal. This possibility, along with limited publicly available technical reporting on Nighthawk, spurred Proofpoint researchers into a technical exploration of the tool and a determination that sharing our findings would be in the best interest of the cybersecurity community. While this report touches on the activity observed in Proofpoint data, the primary focus is Nighthawk’s packer and subsequent payload capabilities. ## Threat Actors <3 Red Teaming Tools ----- Historically, threat actors have integrated legitimate tools into their arsenal for various reasons, such as complicating attribution, leveraging specific features such as endpoint detection evasion capabilities or simply due to ease of use, flexibility, and availability. In the last few years, threat actors from cybercriminals to advanced persistent threat actors have increasingly turned to red teaming tools to achieve their goals. [Between 2019 and 2020, Proofpoint observed a 161% increase in threat actor use of Cobalt](https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware) [Strike. This increase was quickly followed by the adoption of Sliver—an open-source, cross-](https://github.com/BishopFox/sliver/tree/6c02971b54831884d30407b632a379947dd289ad) platform adversary simulation and red team platform. Sliver was first released in 2019 and by December 2020 had been incorporated into threat actors’ tactics, techniques, and procedures—a timeline which could possibly occur with Nighthawk in the future. By late [2021, Proofpoint had identified an initial access facilitator for ransomware threat actors using](https://www.proofpoint.com/us/blog/security-briefs/ta551-uses-sliver-red-team-tool-new-activity) [Sliver. And, as recently as summer 2022, other security researchers have noted a range of](https://www.microsoft.com/en-us/security/blog/2022/08/24/looking-for-the-sliver-lining-hunting-for-emerging-command-and-control-frameworks/) [threat actors of varying skills, resources, and motivations integrating it as well as Brute Ratel,](https://unit42.paloaltonetworks.com/brute-ratel-c4-tool/) another red teaming and adversarial attack simulation tool, into their campaigns. ## Testing, Testing…1…2…3 Proofpoint researchers observed initial use of the Nighthawk framework beginning in midSeptember 2022 with several test emails being sent using generic subjects such as “Just checking in” and “Hope this works2.” Over the course of a few weeks, emails were sent with malicious URLs, that, if clicked, would lead to an ISO file containing the Nighthawk loader payload as a PE32+ executable file, which will be explored in the next section. Proofpoint researchers were able to identify that the payload delivered was the Nighthawk penetration testing framework based on open-source research, including MDSec’s [blog on](https://www.mdsec.co.uk/2022/05/nighthawk-0-2-catch-us-if-you-can/) the latest version of the tool. ## The Loader The Nighthawk loader artifact analyzed by Proofpoint researchers is a PE32+ binary that uses some obfuscation and encryption methods to make analysis more difficult and prolonged. The loader has the following structure (Figure 1) including a .uxgbxd section that contains possibly decoy code and the .text section which contains the main event: the PE entry point, the unpacking code, the configuration structure, and the encrypted Nighthawk payload. ----- _Figure 1. The structure of the Nighthawk PE32+ binary._ The PE entry point (Figure 2) within the .text section implements some control obfuscation by calculating the offset for the main function. This is likely done in order to interfere with static disassembly engines. _Figure 2. PE entry point._ Initially, the loader code builds a small import table and parses a configuration structure that specifies which evasion and keying method are to be used. Functions are dynamically resolved through symbol hashing and manually parsing the export directory of loaded [modules retrieved through the LDR_DATA_TABLE_ENTRY in the](https://www.vergiliusproject.com/kernels/x64/Windows%2010%20%7C%202016/2110%2021H2%20(November%202021%20Update)/_LDR_DATA_TABLE_ENTRY) [PEB. If a desired library is](https://www.vergiliusproject.com/kernels/x64/Windows%2010%20%7C%202016/2110%2021H2%20(November%202021%20Update)/_PEB_LDR_DATA) not present in memory, it is either loaded using LoadLibraryW in a direct call or as a dispatched job via RtlQueueWorkItem. ----- _Figure 3. LoadLibrary implementation._ All meaningful strings are encoded with a simple algorithm and decoded on the fly. This inline string decoding means that for only a brief period of time the strings are present in memory. This creates an advantage for potential threat actors making detection of the tool more difficult. ----- _Figure 4. Loader string encoding._ Some functionality can use WinAPI or direct system calls depending on the corresponding configuration option. This functionality can be used to evade some endpoint detection systems and sandboxes that use usermode hooks for instrumentation. The following code removes any potentially registered ProcessInstrumentationCallback [which can be used to transparently instrument code. This code, if enabled, is directly](https://github.com/ionescu007/HookingNirvana/blob/master/Esoteric%20Hooks.pdf) executed after the configuration parsing and import table setup phase. _Figure 5. Clearing the ProcessInstrumentationCallback._ As another means of evading endpoint detection and response security solutions, the loader code contains optional unhooking functionality for ntdll.dll, kernel32.dll and kernelbase.dll that is intended to remove user mode hooks from system libraries. After initialization, a key for decryption of the payload is derived from one of several system features. Which method is selected to retrieve the payload decryption key is based on user configuration. Supported keying methods are: content of a specified registry key user SID retrieved from the process token account domain SID retrieved with LsaQueryInformationPolicy retrieval of the encryption key via DNS CNAME or TXT query retrieval of the encryption key via HTTPS request username, read with GetUserNameA computer name, read with GetComputerNameA reading the key from a specified file at a specified offset retrieval of the encryption key via DNS over TLS via CNAME or TXT query use of the system drive serial number that is read via IOCTL_STORAGE_QUERY_PROPERTY IOCTL to //./PhysicalDrive0 ----- The presence of these keying methods is one of the clues that led Proofpoint researchers to identify this malware as Nighthawk early on. This list matches the features described in [MDSec’s blog – “Nighthawk 0.2 – Catch Us If You Can”.](https://www.mdsec.co.uk/2022/05/nighthawk-0-2-catch-us-if-you-can/) After a key derivation from the result of the selected keying function, the payload embedded in the .text section is decrypted and executed. The keying feature is engineered to minimize exposure of the cleartext implant and to make it difficult to analyze the malware in a sandbox or lab environment. ## The Nighthawk Payload The Nighthawk payload, which is coded in C++, is embedded as a DLL with a small shellcode prepended (Figure 6) that jumps with the correct offset into the reflective loader code contained within the DLL. _Figure 6. Prepended shellcode._ The DLL contains the following sections: To hide suspicious API calls, Nighthawk uses dynamic API resolution through symbol hashing as well (Figure 7). The correct module and function symbol is identified by checking for a matching hash on the lowercase library name or symbol string. ----- _Figure 7. Nighthawk string hashing function for dynamic API resolution._ This technique is standard tradecraft for malware developers and used in a comparable way in many other malwares and frameworks such as Cobalt Strike. Embedded strings are encoded with a simple substitution cipher. Single characters are looked up in a ciphertext alphabet and replaced with the corresponding character in a cleartext alphabet. If no match in the ciphertext alphabet is found, the character is not substituted. This string encoding is simple but effective in countering signature engines that feature functionality to match XORed strings. Reimplemented string decoding algorithm in Python below. CIPHERTEXT_ALPHABET = ")]9ufjt.,AgU$cwTFzMdxHa!I>hl[ 6QEBmok&;4r? 07G:s^N{qe_P(+b1S8=X/5DvWKiV* 0x28 ret Get the pointer to the [CONTEXT structure for NtContinue from the stack](https://www.vergiliusproject.com/kernels/x64/Windows%2010%20%7C%202016/2110%2021H2%20(November%202021%20Update)/_CONTEXT) pop rcx ret By using these building blocks a ROP chain is constructed that calls VirtualProtect to set the memory of the loaded Nighthawk implant read writable, SystemFunction040/RtlEncryptMemory to encrypt the implant, WaitForSingleObject to sleep, and SystemFunction041/RtlDecryptMemory to decrypt the implant again followed by VirtualProtect to set the memory permissions to read write executable. These functions are invoked through NtContinue with the arguments provided through the CONTEXT structure parameter. Figure 14 illustrates the concept. ----- _Figure 14. Illustration of the no-stub-rop self-encryption method._ ## Outlook Nighthawk is a mature and advanced commercial C2 framework for lawful red team operations that is specifically built for detection evasion, and it does this well. While Proofpoint researchers are not aware of adoption of Nighthawk in the wild by attributed threat actors, it would be incorrect and dangerous to assume that this tool will never be appropriated by threat actors with a variety of intents and purposes. Historic adoption of tools like Brute Ratel by advanced adversaries, including those aligned with state interests and engaging in espionage, provides a template for possible future threat landscape developments. Detection vendors in particular should ensure proper coverage of this tool as cracked versions of effective and flexible post-exploitation frameworks can show up in the dark corners of the internet when either threat actors are looking for a novel tool or the tool has reached a certain prevalence. ----- _Proofpoint researchers will continue to analyze the Nighthawk framework and monitor for_ _threat actor campaigns leveraging the tool. An update to this blog or a follow-up report will be_ _published depending on additional findings._ Subscribe to the Proofpoint Blog -----