{
	"id": "fc6cd92a-9799-4e6b-b183-245468451228",
	"created_at": "2026-04-06T00:22:18.681267Z",
	"updated_at": "2026-04-10T13:11:29.312455Z",
	"deleted_at": null,
	"sha1_hash": "59e0fbc1243a2440e98946f00cec5ecbdd8b075c",
	"title": "MoonWalk | ThreatLabz",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 987627,
	"plain_text": "MoonWalk | ThreatLabz\r\nBy Yin Hong Chang, Sudeep Singh\r\nPublished: 2024-07-11 · Archived: 2026-04-05 13:43:51 UTC\r\nTechnical Analysis\r\nAttack chain\r\nThe focus of this blog post is the second half of the attack chain that begins with the in-memory execution of\r\nMoonWalk backdoor. Once the MoonWalk backdoor is successfully loaded by DodgeBox, the malware decrypts\r\nand reflectively loads two embedded plugins (C2 and Utility). The C2 plugin uses a custom encrypted C2 protocol\r\nto communicate with the attacker-controlled Google Drive account. \r\nA figure depicting the attack chain used to deploy MoonWalk with the DodgeBox loader is shown below.\r\nFigure 1: Attack chain used to deploy the DodgeBox loader and MoonWalk backdoor.\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 1 of 11\n\nMoonWalk analysis\r\nMoonWalk is a malware backdoor written in C that shares many code similarities with DodgeBox, suggesting a\r\ncommon development toolkit. It incorporates many evasion related functions from DodgeBox, including those\r\nrelated to the following:\r\nDLL hollowing \r\nImport resolution \r\nDLL unhooking \r\nCall stack spoofing \r\nAdditionally, MoonWalk utilizes the same DLL blocklist as DodgeBox.\r\nThreatLabz analysis reveals MoonWalk's modular design, allowing it to load different plugin components as\r\nneeded. The sample examined by ThreatLabz contains two embedded plugins, a C2 plugin for C2 communication,\r\nand a utility plugin that provides functionality related to compression and public-key cryptography. This modular\r\narchitecture makes MoonWalk highly adaptable, enabling attackers to customize its functionality for different\r\nscenarios. \r\nIn the section below, we will highlight several notable capabilities of MoonWalk.\r\nUnloading the DodgeBox loader\r\nWhen MoonWalk first initializes, it resolves its imports using the same algorithms as DodgeBox. Then, depending\r\non the DodgeBox configuration parameter  Config.fShouldUnloadStealthVector , MoonWalk unloads the\r\nDodgeBox DLL from memory and unlinks it from the Process Environment Block (PEB). This reduces\r\nMoonWalk’s in-memory footprint, and obfuscates its origins, hindering memory forensic analysis.\r\nUsing Windows Fibers\r\nNext, MoonWalk initializes global structures used to manage Windows Fibers. Windows Fibers are a lightweight\r\nthreading mechanism, available in the Windows operating system since Windows NT SP5. Unlike traditional\r\nthreads, which are scheduled by the operating system, fibers are cooperatively scheduled by the application itself.\r\nThis allows developers to tune an application’s performance for a specific workload. However, due to the\r\ncomplexity of utilizing Windows Fibers, and performance improvements of computer hardware, Windows Fibers\r\nwere not widely adopted, and remains an obscure feature.\r\nHowever, with the increased focus on cybersecurity in recent years, there has been an uptick in interest in\r\nWindows Fibers from the research and red-teaming community. Multiple research papers (1, 2, 3) and open-sourced proof of concepts (POCs) have been published, abusing Windows Fibers to evade AVs/EDR solutions.\r\nAPT41 may have been following these developments, as they have incorporated Windows Fibers into the\r\nMoonWalk backdoor. At a high level, MoonWalk maintains a global array of fibers. When a function needs to be\r\nexecuted as a fiber, a fiber is created using the  CreateFiber API. This fiber is then packaged together with the\r\naddress of the function and its arguments and other metadata, and inserted into the global array. The main fiber\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 2 of 11\n\nthen schedules these fibers for execution. This use of Windows Fibers helps MoonWalk evade AVs and EDRs\r\nwhich do not support the scanning of Windows Fibers, and also makes analysis challenging by breaking up the\r\ncontrol flow.\r\nConfiguration\r\nMoonWalk decrypts its configuration, which is hard-coded within its  .lrsrc section. Like DodgeBox,\r\nMoonWalk uses MD5 for configuration validation and AES Cipher Feedback (AES-CFB) for decryption. \r\nHowever, MoonWalk's configuration is more complex, featuring nested structures and arrays. This configuration\r\ncontains various execution parameters including the following: \r\nMutex names \r\nA fiber configuration \r\nHeartbeat intervals \r\nEncryption keys \r\nC2-related data \r\nIn the sample we analyzed, MoonWalk's configuration (referred to as  Config ) included OAuth secrets used to\r\nauthenticate with the attacker-controlled Google Drive account, and other notable fields as shown below:\r\nConfig.szClientID:\r\nXXXXXXXX3108-0pm3bsjc0mto2e1k4kp2u8817lgk3e3v.apps.googleusercontent.com\r\nConfig.szClientSecret:\r\nXXXXXXXXBiuo8VPZUH1dBHkv86mC1xFU_Z3\r\nConfig.szRefreshToken: XXXXXXXXiYDPmH9cCgYIARAAGAkSNwF-L9IrcM7YiuxWrNuyIfKINyNc_pEVytGNNK750ZyyIm32qH6Wh3dGIBTvdPJ2v92xAohHwWw\r\nConfig.rgbXorKey:\r\na8e6bd132daf0360b1af1f5eea15e42f8c6f1dcd7d34376ae4e83a1a4f5907c0\r\nConfig.szMutexName:\r\nGlobal\\ctXjvsAxpzyqElmk\r\nConfig.szName:\r\ndefault\r\nAfter loading the default configuration, MoonWalk searches for a new configuration file at C:\\ProgramData\\\r\n[MD5(Config.rgbIDBytes)] . If found, the malware decrypts and loads this file. A sample of MoonWalk's\r\ndecrypted configuration is available in the Appendix of this blog for reference.\r\nUnpacking and loading plugins\r\nMoonWalk then extracts embedded plugins from the  .lrsrc section. In the MoonWalk sample we analyzed,\r\nthere were two plugins embedded within this section: one plugin for C2, and another plugin which provides utility\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 3 of 11\n\nfunctions such as public key cryptography and compression.\r\nEach plugin in the  .lrsrc section is prefixed with 72 bytes of metadata, which includes AES-CFB secrets, an\r\nMD5 checksum, and plugin type information. The plugin type information fields provide information about the\r\nfeatures of a plugin. These fields help identify whether a plugin serves as a command handler, C2, or utility. More\r\ndetails about the structure of plugin metadata can be found in the Appendix section.\r\nMoonWalk organizes these plugins by registering them in a global linked list. MoonWalk then goes through this\r\nlist to load the C2 plugin and its dependencies, such as the utility plugin, using DLL hollowing. This process is\r\nsimilar to what we previously described in Part 1 for DodgeBox. Like DodgeBox, this MoonWalk sample stores a\r\ncopy of the host DLL in  C:\\Windows\\Microsoft.NET\\assembly\\GAC_MSIL\\System.Data.Trace .\r\nNetwork Communication\r\nAfter loading the C2 plugin, MoonWalk is prepared to establish communication with the C2 server. MoonWalk\r\nutilizes Google Drive for C2 communications. This helps MoonWalk evade detection, as traffic to and from\r\nreputable cloud services are less likely to raise suspicion, especially if a target is already using this service.\r\nStrangely, MoonWalk uses the string curl/7.54.0 as its User-Agent when making HTTP requests, even though it\r\ndoes not utilize libcurl in its C2 plugin, and uses the WinHTTP family of APIs instead.\r\nAt a high level, MoonWalk communicates over Google Drive in the following manner:\r\nStep Description\r\n1 - Initialization\r\nMoonWalk obtains an access token from the Google Authorization Server, by utilizing\r\nthe OAuth secrets in its configuration ( Config.szClientID ,  Config.szClientSecret\r\nand  Config.szRefreshToken ).\r\nMoonWalk generates 16 random bytes, and hex-encodes them, resulting in a string such\r\nas:  f137da1a9019849fbc2aac49a4b6f2c3. We will reference this string as  SessionID .\r\nMoonWalk uses the Google Drive APIs to retrieve the ID for the  /data directory.\r\nMoonWalk retrieves the ID for the  /data/temp directory.\r\n2 -\r\nCryptographic\r\nHandshake\r\n(Client Hello and\r\nServer Hello)\r\nMoonWalk searches /data/temp for a file named after the\r\ngenerated  SessionID  (i.e.  f137da1a9019849fbc2aac49a4b6f2c3 ). If the file is not\r\nfound, MoonWalk generates and uploads a file  /data/temp/[SessionID] to initiate a\r\ncryptographic handshake and exchange AES keys with the server.\r\nMoonWalk then looks for the  /data/[SessionID]  directory, and its\r\nsubdirectory  /data/[SessionID]/s1 . The directory titled  s[number] seems to serve as\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 4 of 11\n\nStep Description\r\nthe designated location where MoonWalk will retrieve and download forthcoming C2\r\ninstructions.\r\nLastly, MoonWalk searches for the  /data/[SessionID]/s1/1 file. As it becomes\r\navailable, MoonWalk downloads and processes it, and completes the cryptographic\r\nhandshake.\r\n3 - Information\r\nGathering\r\nMoonWalk then checks for the existence of the directory  /data/[SessionID]/c1 , and\r\ncreates it if it does not exist. Then, MoonWalk gathers information such as the computer\r\nname, user name, and OS version, and uploads this to the file  /data/[SessionID]/c1/1 .\r\n4 - Heartbeat\r\nMoonWalk then proceeds to send heartbeats regularly to the C2 server by updating a file\r\nnamed “ temp.txt ” with the current Unix timestamp as a string.\r\nMoonWalk also regularly polls the  /data/[SessionID]/s1 directory for new files. If a\r\nnew file is found, MoonWalk processes it and uploads its response in\r\nthe  /data/[SessionID]/c1 directory. During our analysis of MoonWalk, only ping\r\ncommands were observed, where MoonWalk responded by uploading encoded files to\r\nthe  /data/[SessionID]/c1 directory, containing the current Unix timestamp.\r\nTable 1: High-level view of the MoonWalk C2 communication protocol using Google Drive. \r\nCryptographic Handshake (Client Hello)\r\nDuring the cryptographic handshake phase, MoonWalk exchanges AES keys with the server using a custom\r\nprotocol. Because of this, it becomes very difficult or impossible to decode encrypted C2 messages without access\r\nto these AES keys, which exist only in MoonWalk’s process memory.\r\nThe process begins with MoonWalk generating a 32-byte AES key ( rgbClientAESKey ) and a 16-byte\r\ninitialization vector (IV) ( rgbClientAESIV ) using a custom random number generator. The AES key is then\r\ntreated as an Elliptic-curve Diffie-Hellman (ECDH) private key, to generate the corresponding ECDH public key\r\n( rgbECDHPublicKey ) using the  curve25519_donna function.\r\nMoonWalk then encodes the ECDH public key and AES IV by XORing them with the XOR key from\r\nMoonWalk's configuration ( Config.rgbXorKey ). A checksum is created by performing an MD5 hash on the\r\nconcatenation of  Config.rgbXorKey , ECDH public key, and AES IV, and then taking the hash’s first four bytes.\r\nFinally, MoonWalk uploads this data to Google Drive at the path  /data/temp/[SessionID] .\r\nThe figure below shows content of an uploaded file:\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 5 of 11\n\nFigure 2: Contents of a MoonWalk Client Hello key exchange message.\r\n The table below provides a description of the various fields contained within the uploaded file:\r\nOffset\r\nSize in\r\nbytes\r\nDescription\r\n0x00 1 Unknown field, possibly a message type enum.\r\n0x01 32\r\nrgbECDHPublicKey XORed with  Config.rgbXorKey\r\nrgbECDHPublicKey before the XOR operation is:\r\nd2 04 7b 20 60 c4 25 e2 da 01 f8 1d 5b 89 d1 8c\r\nae bd 07 d3 da bc 82 41 e1 b1 14 2c 57 b5 5a 07\r\n0x21 16\r\nrgbClientAESIV XORed with  Config.rgbXorKey\r\nrgbClientAESIV before the XOR operation is:\r\nc4 e9 27 7c 18 e3 67 c7 49 32 0a a6 f8 be 7a 67\r\n0x31 4\r\nFirst four bytes of  MD5 (Config.rgbXorKey | rgbECDHPublicKey |\r\nrgbClientAESIV)\r\n0x35 15 Unknown bytes.\r\nTable 2: Description of MoonWalk Client Hello key exchange message.\r\nCryptographic Handshake (Server Hello)\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 6 of 11\n\nMoonWalk then downloads the file located at  /data/[SessionID]/s1/1 . This file contains the server’s response\r\nto MoonWalk’s handshake above. \r\nThis file, and all subsequent uploaded or downloaded files, are encoded using a custom scheme. Here, we walk\r\nthrough the decoding process of this scheme, using the Server Hello file as an example.\r\nThe figure below is an example of the overall layout of the encoded Server Hello file:\r\nFigure 3: MoonWalk Server Hello message format.\r\nA description of these fields is shown in the following table.\r\nOffset Size in bytes Description\r\n0x00 8\r\nrgbFileXorKey\r\nThe XOR key used to decode  rgbEncodedBytes .\r\n0x08 8 Unknown, potentially a message type field.\r\n0x10 2\r\ndwNumEncodedBytes\r\nThe number of encoded bytes that follows. This field is encoded\r\nwith  rgbFileXorKey . Decoding this field shows that there are 0xbc\r\nencoded bytes within this file.\r\n85 20XOR85 9c=00 bc\r\n0x12 dwNumEncodedBytes rgbEncodedBytes\r\nThe encoded bytes within this file. These bytes appear to contain message\r\nmetadata, such as Google Drive file IDs, message headers, or junk bytes.\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 7 of 11\n\nOffset Size in bytes Description\r\nTo decode these bytes,  rgbFileXorKey is used, starting with the third\r\nbyte of the XOR key.\r\n18 25 ea a3 39 b4 e8 45 7f 01 99 ba 07 d6\r\nXOR\r\n29 44 ae cd 5f fb 85 20 29 44 ae cd 5f fb\r\n=\r\n31 61 44 6e 66 4f 6d 65 56 45 37 77 58 2d\r\n0x?? variable\r\nrgbEncryptedBytes\r\nThe rest of the file is not encoded, because this section is typically\r\nencrypted with AES-CFB, using the AES keys exchanged during the\r\ncryptographic handshake phase.\r\nTable 3: Description of the MoonWalk Server Hello message format.\r\nThe figure below shows the Server Hello file after decoding:\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 8 of 11\n\nFigure 4: Example contents of a decoded MoonWalk Server Hello message.\r\nThe decoded Server Hello fields are described in the table below.\r\nOffset\r\nSize in\r\nbytes\r\nDescription\r\n0x00 8\r\nrgbFileXorKey\r\nThe XOR key, used to decode  rgbEncodedBytes .\r\n0x08 8 Unknown\r\n0x10 2 dwNumEncodedBytes\r\n0x12 variable\r\nszHeartBeatFileID\r\nThe Google Drive ID of the heartbeat file,  temp.txt .\r\n0x34 variable Unknown\r\n0xce 48\r\nEncoded buffer, XOR encoded with  Config.rgbXorKey .\r\nAfter decoding, the following fields are revealed:\r\n \r\nrgbServerECDHBasePoint - Used as the ECDH base point, which MoonWalk later\r\nuses to generate the shared AES key used by the server.\r\n77 82 64 13 04 16 94 da 35 d2 1e b8 27 d7 35 ff\r\n02 8a 47 85 56 41 29 5b cb 3b 28 22 f2 69 3d 3a\r\nThe remaining bytes after decoding contain a checksum, and additional unknown\r\nbytes.\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 9 of 11\n\nOffset\r\nSize in\r\nbytes\r\nDescription\r\n0xfe 4 Checksum generated by  MD5 (rgbServerECDHBasePoint | Config.rgbXorKey.)\r\n0x102 variable Unknown\r\nTable 4: Description of fields within a MoonWalk Server Hello message.\r\nWith this information, MoonWalk generates a public key ( rgbECDHServerPublicKey ) using\r\nthe  curve25519_donna function. Then,  rgbECDHServerPublicKey  is XORed against  Config.rgbXorKey to\r\ngenerate the server AES key.\r\nCurve25519_Donna(\r\n a1-\u003ergbECDHServerPublicKey,\r\n // Public Key (out):\r\n // 000001e6`246391ec b5 8f a7 ee 0b da d6 79-79 60 85 79 bf 32 ad 91\r\n // 000001e6`246391fc 24 a3 39 66 4c 4b 49 97-6c 71 92 d3 55 45 4b 3e\r\n a1-\u003ergbClientAESKey,\r\n // Private Key:\r\n // 000001e6`2463920c 54 be fd a7 f4 0f 62 15-fb 22 9a 48 04 e3 6e 90\r\n // 000001e6`2463921c 85 4b b9 c7 f2 5f de 57-65 59 9c 90 18 04 d9 d1\r\n a1-\u003ergbECDHServerBasepoint);\r\n // Basepoint:\r\n // 000001e6`24639251 77 82 64 13 04 16 94 da-35 d2 1e b8 27 d7 35 ff\r\n // 000001e6`24639261 02 8a 47 85 56 41 29 5b-cb 3b 28 22 f2 69 3d 3a\r\nrgbServerAESKey = rgbECDHServerPublicKey ^ Config.rgbXorKey\r\n// 1d 69 1a fd 26 75 d5 19-c8 cf 9a 27 55 27 49 be\r\n// a8 cc 24 ab 31 7f 7e fd-88 99 a8 c9 1a 1c 4c fe\r\nIn this manner, MoonWalk exchanges AES keys with its C2, and thus concludes the cryptographic handshake.\r\nInformation gathering\r\nDuring this phase, MoonWalk collects information about the environment and uploads it to Google Drive. The\r\ngathered data includes details such as the processor architecture, Windows product type, version and build\r\nnumbers, computer and usernames, as well as IP addresses. This information is then compressed using LZ4. A\r\nchecksum is then added, using the 32-bit MurmurHash2 algorithm, with a customized mixing constant where  r\r\nis set to  15 , and with the initial seed set to  0x12345678 . These bytes are then encrypted using AES-CFB with\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 10 of 11\n\nthe server’s AES key, and packaged using the custom scheme detailed above, before being uploaded to Google\r\nDrive.\r\nMore details of the environment information collected are provided in the Appendix of this blog.\r\nHeartbeat\r\nMoonWalk also regularly sends heartbeats to the server. It uploads the current Unix timestamp in plain text to\r\na  temp.txt file on Google Drive, using the file ID  szHeartBeatFileID retrieved as part of the cryptographic\r\nhandshake.\r\nBackdoor capabilities\r\nIn our analysis of MoonWalk, we did not observe the C2 sending any other commands or plugins. If a command\r\nhandler plugin ( dwPluginTypePart2 == 1 described in the Appendix) is not found, MoonWalk defaults to a\r\nbuilt-in list of handlers. These handlers contain functionality, which include the following:\r\nCollect environment information (similar to the information gathering step above)\r\nSteal token (token impersonation)\r\nCreate token (log on to the Windows machine using given credentials)\r\nDownload new configuration\r\nExecute command line commands\r\nNote: This list is not complete as further analysis is required.\r\nExplore more Zscaler blogs\r\nSource: https://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nhttps://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/moonwalk-deep-dive-updated-arsenal-apt41-part-2"
	],
	"report_names": [
		"moonwalk-deep-dive-updated-arsenal-apt41-part-2"
	],
	"threat_actors": [
		{
			"id": "4d5f939b-aea9-4a0e-8bff-003079a261ea",
			"created_at": "2023-01-06T13:46:39.04841Z",
			"updated_at": "2026-04-10T02:00:03.196806Z",
			"deleted_at": null,
			"main_name": "APT41",
			"aliases": [
				"WICKED PANDA",
				"BRONZE EXPORT",
				"Brass Typhoon",
				"TG-2633",
				"Leopard Typhoon",
				"G0096",
				"Grayfly",
				"BARIUM",
				"BRONZE ATLAS",
				"Red Kelpie",
				"G0044",
				"Earth Baku",
				"TA415",
				"WICKED SPIDER",
				"HOODOO",
				"Winnti",
				"Double Dragon"
			],
			"source_name": "MISPGALAXY:APT41",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "e698860d-57e8-4780-b7c3-41e5a8314ec0",
			"created_at": "2022-10-25T15:50:23.287929Z",
			"updated_at": "2026-04-10T02:00:05.329769Z",
			"deleted_at": null,
			"main_name": "APT41",
			"aliases": [
				"APT41",
				"Wicked Panda",
				"Brass Typhoon",
				"BARIUM"
			],
			"source_name": "MITRE:APT41",
			"tools": [
				"ASPXSpy",
				"BITSAdmin",
				"PlugX",
				"Impacket",
				"gh0st RAT",
				"netstat",
				"PowerSploit",
				"ZxShell",
				"KEYPLUG",
				"LightSpy",
				"ipconfig",
				"sqlmap",
				"China Chopper",
				"ShadowPad",
				"MESSAGETAP",
				"Mimikatz",
				"certutil",
				"njRAT",
				"Cobalt Strike",
				"pwdump",
				"BLACKCOFFEE",
				"MOPSLED",
				"ROCKBOOT",
				"dsquery",
				"Winnti for Linux",
				"DUSTTRAP",
				"Derusbi",
				"ftp"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "2a24d664-6a72-4b4c-9f54-1553b64c453c",
			"created_at": "2025-08-07T02:03:24.553048Z",
			"updated_at": "2026-04-10T02:00:03.787296Z",
			"deleted_at": null,
			"main_name": "BRONZE ATLAS",
			"aliases": [
				"APT41 ",
				"BARIUM ",
				"Blackfly ",
				"Brass Typhoon",
				"CTG-2633",
				"Earth Baku ",
				"GREF",
				"Group 72 ",
				"Red Kelpie ",
				"TA415 ",
				"TG-2633 ",
				"Wicked Panda ",
				"Winnti"
			],
			"source_name": "Secureworks:BRONZE ATLAS",
			"tools": [
				"Acehash",
				"CCleaner v5.33 backdoor",
				"ChinaChopper",
				"Cobalt Strike",
				"DUSTPAN",
				"Dicey MSDN",
				"Dodgebox",
				"ForkPlayground",
				"HUC Proxy Malware (Htran)"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434938,
	"ts_updated_at": 1775826689,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/59e0fbc1243a2440e98946f00cec5ecbdd8b075c.pdf",
		"text": "https://archive.orkl.eu/59e0fbc1243a2440e98946f00cec5ecbdd8b075c.txt",
		"img": "https://archive.orkl.eu/59e0fbc1243a2440e98946f00cec5ecbdd8b075c.jpg"
	}
}