{ "id": "bd6d2225-34f0-41e3-b80f-1ac618db7c93", "created_at": "2026-04-06T00:12:01.802607Z", "updated_at": "2026-04-10T03:24:23.882111Z", "deleted_at": null, "sha1_hash": "219cace8ef6e5ac4a609bae597ea109c89ebde5a", "title": "Studying “Next Generation Malware” - NightHawk’s Attempt At Obfuscate and Sleep", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 69568, "plain_text": "Studying “Next Generation Malware” - NightHawk’s Attempt At\r\nObfuscate and Sleep\r\nBy Austin Hudson\r\nPublished: 2022-05-05 · Archived: 2026-04-05 18:54:09 UTC\r\nOver the last year and a half, I’ve often seen mentions of a self-proclaimed “next generation malware” of the name\r\nNightHawk. Ordinarily, I’d know most of those claims tend to be nothing more than hubris, and choose to ignore\r\nit, but, I get bored. As such, I’ve chosen to start analyzing and tearing about the malware based on samples I\r\nacquired via VirusTotal, a hub which contains a plethora of commercial, closed-source, and open source samples.\r\nThis research is done on my own time, and is not associated with anyone other than myself. I’ve torn about other\r\nsimiliar malware such as Beacon from Cobalt Strike.\r\nTLDR: A very simple, yet effective technique. Can this be replicated with ease? Yes! Was it something new?\r\nFortunately, no. A little dissapointed? A bit.\r\nUnderstanding its PE-SIEVE / Moneta Evasion\r\nA while back, a friend of mine notified me about a video which proclaimed that it was capable of circumventing\r\nHasherezade’s memory scanning tool PE-SIEVE, as well as Forrest’s Moneta, something that peaked my interest,\r\nas I had developed a similiar capability a few years prior, to improve the original research named Gargoyle for\r\nx86/x64/WOW64.\r\nAt first, I was intrigued about the technique. Was there perhaps an easier method that I had missed? Fortunutely\r\nfor me, not so much. Further study revealed that it supported numerous sleeping methods, such as leveraging\r\nNtSignalAndWaitForSingleObject by notifying an event, then awaiting on the current process while remaining\r\nnon-alertable, or by leveraging NtWaitForSingleObject to await on the current process object as non-alertable.\r\nEvt = CreateEventW( NULL, 0, 0, NULL );\r\nif ( Evt != NULL ) {\r\n Nst = NtSignalAndWaitForSingleObject( Evt, NtCurrentProcess(), FALSE, \u0026Del );\r\n}\r\nPseudo-C demonstrating the underlying concept of using NtSignalAndWaitForSingleObject\r\nNothing new, fortunately. Its used as a means of circumventing the check on Hunting-Sleeping-Beacons to hide\r\ndetections based on the DelayExecution wait status for threads. Its certainly sufficient, and something I was\r\ndoing myself.\r\nHowever, its evasion to hide traces of itself in memory are a little different. It first ( I believe ) leverages\r\nRtlCaptureContext as a callback to kernel32!CreateTimerQueueTimer with an argument to a context structure\r\nhttps://web.archive.org/web/20220505170100/https://suspicious.actor/2022/05/05/mdsec-nighthawk-study.html\r\nPage 1 of 3\n\nto capture the return address value to return to. A call below would replicate the similiar behavior:\r\nif ( CreateTimerQueueTimer( \u0026TimerObj, TimerQueue, RtlCaptureContext, ContextStruct, 0, 0, WT_EXECUTEINTIMERTHR\r\n{\r\n WaitForSingleObject( TimerObj, 50 );\r\n}\r\nThe callback will promptly be executed within a new thread, and on x64, RSP will be filled with the complete\r\nreturn address. After this has completed, NightHawk then fills in the function-call CONTEXT structures for\r\nVirtualProtect , SuspendThread , GetThreadContext , SetThreadContext , and ResumeThread . These\r\ncontext structures allow NightHawk to redirect execution to the specified functions with full control over RSP ,\r\nRCX , RDX , R8 , R9 .\r\nIt does not have any further control over any functions that are over 4 arguments on x64, due to the usage of\r\ntimers and heavy reliance on its termination callback from calling the specified callback. Furthermore, it adjusts\r\nRSP back to 8 bytes to accomodate the offset created by calling RtlCaptureContext .\r\n__builtin_memcpy( \u0026 ContextVirtualProtect, \u0026 ContextStructure, sizeof( ContextStructure ) );\r\nContextVirtualProtect.Rsp -= 8;\r\nContextVirtualProtect.Rip = VirtualProtect\r\nContextVirtualProtect.Rcx = NightHawkImageBase;\r\nContextVirtualProtect.Rdx = NightHawkImageLength;\r\nContextVirtualProtect.R8 = PAGE_READWRITE\r\nContextVirtualProtect.R9 = \u0026OriginalProtect;\r\n__builtin_memcpy( \u0026 ContextSuspendThread, \u0026 ContextStructure, sizeof( ContextStructure ) );\r\nContextSuspendThread.Rsp -= 8;\r\nContextSuspendThread.Rip = SuspendThread;\r\nContextSuspendThread.Rcx = MyOriginalThreadHandle;\r\nOnce the call has been built, it then attempts to queue it using the same timer function with a callback set to either\r\nNtContinue or RtlRestoreContext which will leverage the context structure to execute the specified function\r\nwith the set registers and return safely without causing a potential crash - While promptly adjusting the timing\r\nperiod between the calls to avoid any functions from being queued out of order.\r\nLARGE_INTEGER Time;\r\nRtlSecureZeroMemory( \u0026Time, sizeof( Time ) );\r\nTime.QuadPart += 100;\r\nCreateTimerQueueTimer( TimerObj, TimerQueue, RtlRestoreContext, \u0026ContextVirtualProtect, \u0026Time, 0, WT_EXECUTEINTI\r\nTime.QuadPart += 100;\r\nhttps://web.archive.org/web/20220505170100/https://suspicious.actor/2022/05/05/mdsec-nighthawk-study.html\r\nPage 2 of 3\n\nCreateTimerQueueTimer( TimerObj, TimerQueue, RtlRestoreContext, \u0026ContextSuspendThread, \u0026Time, 0,\r\nWT_EXECUTEINTIMERTHREAD );\r\nAs a result, the timer queue will first execute ContextVirtualProtect, before ContextSuspendThread to avoid issues\r\nof them conflicting or running before the other has completed safely. But first! To avoid issues of the calls running\r\nbefore it has reached a waitable state, it will then use WaitForSingleObject to block until the timer queue has\r\ncompleted. A very similiar style to how I accomplished my Foliage/Gargyoyle chain a few years ago, yet just as\r\neffective.\r\nI will be sharing my PoC in the coming days replicating their varition to completion. For those of you who utilize\r\nCobalt or other similiar toolsets, and dont want to waste $30K, fortunately, this can be achieved with very little\r\neffort and tooling using something like a custom Reflective Loader, which I will be re-posting my Titan variant\r\nwith their implementation contained.\r\nSource: https://web.archive.org/web/20220505170100/https://suspicious.actor/2022/05/05/mdsec-nighthawk-study.html\r\nhttps://web.archive.org/web/20220505170100/https://suspicious.actor/2022/05/05/mdsec-nighthawk-study.html\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://web.archive.org/web/20220505170100/https://suspicious.actor/2022/05/05/mdsec-nighthawk-study.html" ], "report_names": [ "mdsec-nighthawk-study.html" ], "threat_actors": [ { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434321, "ts_updated_at": 1775791463, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/219cace8ef6e5ac4a609bae597ea109c89ebde5a.pdf", "text": "https://archive.orkl.eu/219cace8ef6e5ac4a609bae597ea109c89ebde5a.txt", "img": "https://archive.orkl.eu/219cace8ef6e5ac4a609bae597ea109c89ebde5a.jpg" } }