{
	"id": "a7bae654-663a-4cdd-b511-e8c038121ff1",
	"created_at": "2026-04-06T00:06:26.745368Z",
	"updated_at": "2026-04-10T13:12:54.996352Z",
	"deleted_at": null,
	"sha1_hash": "1a4bf6857b894fa152fe60deb8fe5b4786383824",
	"title": "Nighthawk: An Up-and-Coming Pentest Tool Likely to Gain Threat Actor Notice | Proofpoint US",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1248490,
	"plain_text": "Nighthawk: An Up-and-Coming Pentest Tool Likely to Gain\r\nThreat Actor Notice | Proofpoint US\r\nBy Alexander Rausch and the Proofpoint Threat Research Team\r\nPublished: 2022-11-18 · Archived: 2026-04-05 19:33:15 UTC\r\nKey Takeaways\r\nNighthawk is an advanced C2 framework intended for red team operations through commercial licensing. \r\nProofpoint researchers observed initial use of the framework in September 2022 by a likely red team.\r\nWe have seen no indications at this time that leaked versions of Nighthawk are being used by attributed\r\nthreat actors in the wild.\r\nThe tool has a robust list of configurable evasion techniques that are referenced as “opsec” functions\r\nthroughout its code.\r\nProofpoint researchers expect Nighthawk will show up in threat actor campaigns as the tool becomes more\r\nwidely recognized or as threat actors search for new, more capable tools to use against targets.\r\nOverview\r\nIn September 2022, Proofpoint researchers identified initial delivery of a penetration testing framework called\r\nNighthawk. Launched in late 2021 by MDSec, Nighthawk is similar to other frameworks such as Brute\r\nRatel and Cobalt Strike and, like those, could see rapid adoption by threat actors wanting to diversify their\r\nmethods and add a relatively unknown framework to their arsenal. This possibility, along with limited publicly\r\navailable technical reporting on Nighthawk, spurred Proofpoint researchers into a technical exploration of the tool\r\nand a determination that sharing our findings would be in the best interest of the cybersecurity community. \r\nWhile this report touches on the activity observed in Proofpoint data, the primary focus is Nighthawk’s packer and\r\nsubsequent payload capabilities. \r\nThreat Actors \u003c3 Red Teaming Tools\r\nHistorically, threat actors have integrated legitimate tools into their arsenal for various reasons, such as\r\ncomplicating attribution, leveraging specific features such as endpoint detection evasion capabilities or simply due\r\nto ease of use, flexibility, and availability. In the last few years, threat actors from cybercriminals to advanced\r\npersistent threat actors have increasingly turned to red teaming tools to achieve their goals. \r\nBetween 2019 and 2020, Proofpoint observed a 161% increase in threat actor use of Cobalt Strike. This increase\r\nwas quickly followed by the adoption of Sliver—an open-source, cross-platform adversary simulation and red\r\nteam platform. Sliver was first released in 2019 and by December 2020 had been incorporated into threat actors’\r\ntactics, techniques, and procedures—a timeline which could possibly occur with Nighthawk in the future. By late\r\n2021, Proofpoint had identified an initial access facilitator for ransomware threat actors using Sliver. And, as\r\nrecently as summer 2022, other security researchers have noted a range of threat actors of varying skills,\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 1 of 17\n\nresources, and motivations integrating it as well as Brute Ratel, another red teaming and adversarial attack\r\nsimulation tool, into their campaigns. \r\nTesting, Testing…1…2…3\r\nProofpoint researchers observed initial use of the Nighthawk framework beginning in mid-September 2022 with\r\nseveral test emails being sent using generic subjects such as “Just checking in” and “Hope this works2.” Over the\r\ncourse of a few weeks, emails were sent with malicious URLs, that, if clicked, would lead to an ISO file\r\ncontaining the Nighthawk loader payload as a PE32+ executable file, which will be explored in the next section.\r\nProofpoint researchers were able to identify that the payload delivered was the Nighthawk penetration testing\r\nframework based on open-source research, including MDSec’s blog on the latest version of the tool.\r\nThe Loader \r\nThe Nighthawk loader artifact analyzed by Proofpoint researchers is a PE32+ binary that uses some obfuscation\r\nand encryption methods to make analysis more difficult and prolonged. The loader has the following structure\r\n(Figure 1) including a .uxgbxd section that contains possibly decoy code and the .text section which contains the\r\nmain event: the PE entry point, the unpacking code, the configuration structure, and the encrypted Nighthawk\r\npayload.\r\nFigure 1. The structure of the Nighthawk PE32+ binary.\r\nThe PE entry point (Figure 2) within the .text section implements some control obfuscation by calculating the\r\noffset for the main function. This is likely done in order to interfere with static disassembly engines.\r\nFigure 2. PE entry point.\r\nInitially, the loader code builds a small import table and parses a configuration structure that specifies which\r\nevasion and keying method are to be used. Functions are dynamically resolved through symbol hashing and\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 2 of 17\n\nmanually parsing the export directory of loaded modules retrieved through the LDR_DATA_TABLE_ENTRY in\r\nthe PEB. If a desired library is not present in memory, it is either loaded using LoadLibraryW in a direct call or as\r\na dispatched job via RtlQueueWorkItem.\r\nFigure 3. LoadLibrary implementation.\r\nAll meaningful strings are encoded with a simple algorithm and decoded on the fly. This inline string decoding\r\nmeans that for only a brief period of time the strings are present in memory. This creates an advantage for\r\npotential threat actors making detection of the tool more difficult.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 3 of 17\n\nFigure 4. Loader string encoding.\r\nSome functionality can use WinAPI or direct system calls depending on the corresponding configuration option.\r\nThis functionality can be used to evade some endpoint detection systems and sandboxes that use usermode hooks\r\nfor instrumentation.\r\nThe following code removes any potentially registered ProcessInstrumentationCallback which can be used to\r\ntransparently instrument code. This code, if enabled, is directly executed after the configuration parsing and\r\nimport table setup phase.\r\nFigure 5. Clearing the ProcessInstrumentationCallback.\r\nAs another means of evading endpoint detection and response security solutions, the loader code contains optional\r\nunhooking functionality for ntdll.dll, kernel32.dll and kernelbase.dll that is intended to remove user mode hooks\r\nfrom system libraries. \r\nAfter initialization, a key for decryption of the payload is derived from one of several system features. Which\r\nmethod is selected to retrieve the payload decryption key is based on user configuration.\r\nSupported keying methods are:\r\ncontent of a specified registry key\r\nuser SID retrieved from the process token\r\naccount domain SID retrieved with LsaQueryInformationPolicy\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 4 of 17\n\nretrieval of the encryption key via DNS CNAME or TXT query\r\nretrieval of the encryption key via HTTPS request\r\nusername, read with GetUserNameA\r\ncomputer name, read with GetComputerNameA\r\nreading the key from a specified file at a specified offset\r\nretrieval of the encryption key via DNS over TLS via CNAME or TXT query\r\nuse of the system drive serial number that is read via IOCTL_STORAGE_QUERY_PROPERTY IOCTL to\r\n//./PhysicalDrive0\r\nThe presence of these keying methods is one of the clues that led Proofpoint researchers to identify this malware\r\nas Nighthawk early on. This list matches the features described in MDSec’s blog – “Nighthawk 0.2 – Catch Us If\r\nYou Can”.\r\nAfter a key derivation from the result of the selected keying function, the payload embedded in the .text section is\r\ndecrypted and executed. The keying feature is engineered to minimize exposure of the cleartext implant and to\r\nmake it difficult to analyze the malware in a sandbox or lab environment.\r\nThe Nighthawk Payload\r\nThe Nighthawk payload, which is coded in C++, is embedded as a DLL with a small shellcode prepended (Figure\r\n6) that jumps with the correct offset into the reflective loader code contained within the DLL.\r\nFigure 6. Prepended shellcode.\r\nThe DLL contains the following sections:\r\nTo hide suspicious API calls, Nighthawk uses dynamic API resolution through symbol hashing as well (Figure 7).\r\nThe correct module and function symbol is identified by checking for a matching hash on the lowercase library\r\nname or symbol string.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 5 of 17\n\nFigure 7. Nighthawk string hashing function for dynamic API resolution.\r\nThis technique is standard tradecraft for malware developers and used in a comparable way in many other\r\nmalwares and frameworks such as Cobalt Strike.\r\nEmbedded strings are encoded with a simple substitution cipher. Single characters are looked up in a ciphertext\r\nalphabet and replaced with the corresponding character in a cleartext alphabet. If no match in the ciphertext\r\nalphabet is found, the character is not substituted.\r\nThis string encoding is simple but effective in countering signature engines that feature functionality to match\r\nXORed strings.\r\nReimplemented string decoding algorithm in Python below.\r\nCIPHERTEXT_ALPHABET = \")]9ufjt.,AgU$cwTFzMdxHa!I\u003ehl[ 6QEBmok\u0026;4r?\r\n07G:s^N{qe_P(+b1S8=X/5DvWKiV*\u003cO}-ZnpJ3yYL2RC\" \r\nCLEARTEXT_ALPHABET = \",lDvbd\u003c)!asg\u003e.B-GNoK\u00269P$;6c3O_hFHJqQm4r0y]wtk:{(8xX^EjT?\r\nCen}+z=/5SIViu2*ZY[pURW1f L7MA\" \r\ndef decode_string(encoded): \r\n   d = [] \r\n   for c in encoded: \r\n       if c in CIPHERTEXT_ALPHABET: \r\n           d.append(CLEARTEXT_ALPHABET[CIPHERTEXT_ALPHABET.find(c)]) \r\n       else: \r\n           d.append(c) \r\n   return \"\".join(d) \r\nNighthawk loads a configuration profile from the .profile section after some initial setup work.\r\nThe embedded profile itself is a gzip compressed and AES encrypted JSON object where the string type fields are\r\nencoded with the substitution cipher described above. The 128bit AES key is either prepended to the encrypted\r\nconfiguration profile or retrieved via HTTPS or DNS.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 6 of 17\n\nFigure 8. Encrypted profile configuration.\r\nFigure 9. Decrypted and decompressed profile configuration.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 7 of 17\n\nFigure 10. Partial Nighthawk configuration profile with additional string decoding.\r\nNighthawk Evasion \r\nNighthawk features an extensive list of configurable evasion techniques that are referenced as “opsec” functions\r\nthroughout its code. These techniques are important because they include capabilities that prevent certain endpoint\r\ndetection notifications and evade process memory scans.\r\nProofpoint researchers identified the numerous following evasion options that can be specified in the opsec\r\nsection of the configuration profile. Some of these capabilities are explained in MDSec’s blog while others have\r\nnot been sufficiently publicly documented. It is on the latter capabilities where we have focused our analysis—\r\ndetails of which can be found after this table.\r\nOpsec\r\nConfiguration\r\nOption\r\nFunctionality\r\nuse-syscalls  Use direct system calls instead of WinApi where applicable.\r\nindirect-syscalls \r\nUse indirect system calls by setting up system call arguments and calling a syscall\r\ninstruction in ntdll instead of a syscall instruction inside the Nighthawk code.\r\nunhook-syscalls  Remove hooks from ntdll.dll\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 8 of 17\n\nself-encrypt-mode \r\nValid options are:\r\noff\r\nstub\r\nno-stub-rop\r\nno-stub-timer\r\nno-stub-regwait\r\nself-encrypt-after  The exact functionality is unknown at the time of writing.\r\nreport-self-encrypt-status \r\nThe exact functionality is unknown at the time of writing.\r\nself-encrypt-while-listening \r\nThe exact functionality is unknown at the time of writing.\r\nstomp-pe-header \r\nOverwrites the DOS header magic value, the space between the DOS and PE header,\r\nthe PE magic and section names.\r\nmasquerade-thread-stacks\r\nThis option overwrites the stack of threads during hibernation.\r\nencrypt-heap-mode\r\nEncrypts the heap when the implant hibernates.\r\nValid options are:\r\noff\r\nimplant\r\nimplant+zero\r\nclear-veh-on-unhookThis option temporarily sets a dummy exception handler by patching the\r\nLdrpVectorHandlerList during import resolution.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 9 of 17\n\nclear-veh-on-imp-res\r\nThis option temporarily sets a dummy exception handler by patching the\r\nLdrpVectorHandlerList during import resolution.\r\nclear-hwbp-on-unhookThis option clears all hardware breakpoints via NtSetContextThread during the\r\nusermode hook removal process.\r\nclear-hwbp-on-imp-resThis option clears all hardware breakpoints via NtSetContextThread during API\r\nresolution.\r\nclear-dll-notificationsThis setting clears the list of DLL loading notification callbacks registered with\r\nLdrRegisterDllNotification.\r\nuse-threadpool Use RtlQueueWorkItem to dispatch tasks to a thread pool.\r\nbacking-module The exact functionality is unknown at the time of writing. \r\nunhook-dlls Remove usermode hooks from the list of specified DLLs.\r\nblock-dlls Block the specified DLLs from being loaded by hooking LoadLibraryExW.\r\nuse-hwbp-for\r\nUse hardware breakpoints to implement hooking for the specified features.\r\nValid options are:\r\nimplant+zero \r\ninproc-console\r\nblock-dlls\r\npatch-etw-event\r\npatch-etw-control\r\npatch-amsi\r\nunhook-using-wpm Overwrite hooks using WriteProcessMemory.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 10 of 17\n\nunhook-via-native Overwrite hooks using NtProtectVirtualMemory and memmove (intrinsic).\r\nunhook-clear-guard\r\nClear the PAGE_GUARD permission from inaccessible memory and set the\r\npermissions for PAGE_NO_ACCESS memory to PAGE_EXECUTE_READ.\r\nhide-windows\r\nHide GUI Windows of the Nighthawk process using EnumWindows and\r\nShowWindow.\r\nsleep-mode\r\nSelects a sleep mechanism.\r\nValid options are:\r\nsleep: SleepEx\r\ndelay: NtDelayExecution\r\nwait-single:  NtWaitForSingleObject\r\nwait-multi: NtWaitForMultipleObjects\r\nwait-signal: CreateEventW  and NtSignalAndWaitForSingleObject\r\ndisable-pi-callback\r\nDisable process instrumentation callbacks by using NtSetInformationProcess to set\r\nthe ProcessInstrumentationCallback information class.\r\npatch-etw-event Hook NtTraceEvent.\r\npatch-etw-control Hook NtTraceControl.\r\npatch-amsi Hook AmsiScanBuffer.\r\nthreadpool-loadlibrary\r\nUse RtlQueueWorkItem to dispatch calls to LoadLibraryW for library loading.\r\nthread-start-addresses\r\nThe exact functionality is unknown at the time of writing.\r\nDLL load notification removal (unhook-dlls): Nighthawk implements a technique that can prevent endpoint\r\ndetection products from receiving notifications for newly loaded DLLs in the current process context via callbacks\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 11 of 17\n\nthat were registered with LdrRegisterDllNotification. This technique is enabled by the clear-dll-notifications\r\noption.\r\nThe intended way to unregister a DLL load notification callback is to use LdrUnregisterDllNotification; however,\r\nthis requires a cookie value that is returned by the initial LdrRegisterDllNotification. Nighthawk works around\r\nthis by directly modifying the list of structures that store callbacks for a given process.\r\nFigure 11. Reversed nh_opsec_unregister_dll_load_notifications function.\r\nOf particular interest is the technique used to find the head of the LdrpDllNotificationList (Figure 12).\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 12 of 17\n\nFigure 12. Reversed nh_get_LdrpDllNotificationList function.\r\nThe head of LdrpDllNotificationList is in the .data section of ntdll.dll and the cookie value returned by\r\nLdrRegisterDllNotification is a pointer to a list entry in LdrpDllNotificationList.\r\nThus, walking this list leads to a list entry located inside the ntdll.dll .data section and this list entry is the head of\r\nLdrpDllNotificationList. This implementation is much more stable than other implementations that rely on\r\ndisassembling code referencing LdrpDllNotificationList in ntdll.dll.\r\nDisabling process instrumentation callback (disable-pi-callback): Nighthawk disables this callback by setting\r\nan empty callback using NtSetInformationProcess similar to the implementation used in the loader.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 13 of 17\n\nFigure 13. Reversed nh_disable_process_instrumentation_callback function.\r\nSelf-encryption (self-encryption-mode): Modern C2 frameworks often implement self-encryption capabilities to\r\nevade process memory scans. Nighthawk implements several variants of self-encryption methods that can be\r\nconfigured with the self-encrypt-mode option.\r\nThe advanced, more interesting options are no-stub-rop, no-stub-timer, and no-stub-regwait.\r\nAll these options are implemented without any resident code but rather use a ROP chain or callbacks to directly\r\ncall into the APIs used to encrypt, sleep, and finally decrypt the implant by proxy through NtContinue. When this\r\ncode is executed, all other threads are already suspended and have a spoofed stack depending on the configuration\r\nof the masquerade-thread-stacks option.\r\nThe no-stub implementations generally use SystemFunction040/RtlEncryptMemory and\r\nSystemFunction041/RtlDecryptMemory to implement the encryption and decryption functionality. NtContinue is\r\nused as a “super gadget” to invoke these APIs with the correct set of parameters. NtWaitForSingleObject,\r\nRegisterWaitForSingleObject, and CreateQueueTimer are used to implement a sleep primitive for the three\r\noptions respectively.\r\nAll of these methods are sophisticated and relatively hard to detect but the most eye-catching implementation is\r\nthe no-stub-rop option. This self-encryption method uses return oriented programming to implement the\r\nencryption logic by constructing a ROP chain consisting of the following two code gadgets (note: gadgets are\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 14 of 17\n\ndynamically discovered by iterating modules present in the PEB InLoadOrderModuleList) and the NtContinue\r\n“super gadget”:\r\nIncrement the stack pointer\r\nadd rsp, value \u003e 0x28\r\nret\r\nGet the pointer to the CONTEXT structure for NtContinue from the stack\r\npop rcx\r\nret\r\nBy using these building blocks a ROP chain is constructed that calls VirtualProtect to set the memory of the\r\nloaded Nighthawk implant read writable, SystemFunction040/RtlEncryptMemory to encrypt the implant,\r\nWaitForSingleObject to sleep, and SystemFunction041/RtlDecryptMemory to decrypt the implant again followed\r\nby VirtualProtect to set the memory permissions to read write executable. These functions are invoked through\r\nNtContinue with the arguments provided through the CONTEXT structure parameter.\r\nFigure 14 illustrates the concept.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 15 of 17\n\nFigure 14. Illustration of the no-stub-rop self-encryption method.\r\nOutlook\r\nNighthawk is a mature and advanced commercial C2 framework for lawful red team operations that is specifically\r\nbuilt for detection evasion, and it does this well. While Proofpoint researchers are not aware of adoption of\r\nNighthawk in the wild by attributed threat actors, it would be incorrect and dangerous to assume that this tool will\r\nnever be appropriated by threat actors with a variety of intents and purposes. Historic adoption of tools like Brute\r\nRatel by advanced adversaries, including those aligned with state interests and engaging in espionage, provides a\r\ntemplate for possible future threat landscape developments. Detection vendors in particular should ensure proper\r\ncoverage of this tool as cracked versions of effective and flexible post-exploitation frameworks can show up in the\r\ndark corners of the internet when either threat actors are looking for a novel tool or the tool has reached a certain\r\nprevalence.\r\nProofpoint researchers will continue to analyze the Nighthawk framework and monitor for threat actor campaigns\r\nleveraging the tool. An update to this blog or a follow-up report will be published depending on additional\r\nfindings.\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 16 of 17\n\nSource: https://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-l\r\nikely-gain-threat-actor-notice\r\nhttps://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://web.archive.org/web/20221124020920/https://www.proofpoint.com/us/blog/threat-insight/nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice"
	],
	"report_names": [
		"nighthawk-and-coming-pentest-tool-likely-gain-threat-actor-notice"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775433986,
	"ts_updated_at": 1775826774,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1a4bf6857b894fa152fe60deb8fe5b4786383824.pdf",
		"text": "https://archive.orkl.eu/1a4bf6857b894fa152fe60deb8fe5b4786383824.txt",
		"img": "https://archive.orkl.eu/1a4bf6857b894fa152fe60deb8fe5b4786383824.jpg"
	}
}