{
	"id": "ed396762-009a-4482-b927-cd355a41ffdb",
	"created_at": "2026-04-06T00:22:14.619301Z",
	"updated_at": "2026-04-10T03:20:27.064883Z",
	"deleted_at": null,
	"sha1_hash": "caae5d01e3fab72661d45cb29423bd64e16e32d9",
	"title": "IcedID – Technical Analysis of an IcedID Lightweight x64 DLL - 0x0d4y Malware Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1955264,
	"plain_text": "IcedID – Technical Analysis of an IcedID Lightweight x64 DLL - 0x0d4y\r\nMalware Research\r\nBy 0x0d4y\r\nPublished: 2024-04-08 · Archived: 2026-04-05 23:33:15 UTC\r\nMy first public malware research was regarding an x32 PE stager (exe) from the IcedID family. In this research I analyzed\r\nthree samples from different years, with the aim of identifying code reuse, and developing a Yara signature capable of\r\ndetecting any IcedID sample, based on fixed code patterns persistent over the years.\r\nSo you may be asking me: “why make another one?“.\r\nWell, I would answer: “Because my friend techevo posted a sample on MalwareBazaar of an IcedID x64 DLL,\r\nand that sample didn’t match the signature I developed in my research!“\r\nWell, because of that, I previously analyzed the sample, to understand what was different between the samples I analyzed\r\npreviously, and this one. And it was so fun, that I decided to publish another article showing another face of IcedID.\r\nTherefore, in this article I will focus on the following aspects of analysis:\r\nLoader Reverse Engineering, to understand how this x64 DLL version of IcedID is loaded into memory;\r\nReverse Engineering of the x64 IcedID DLL;\r\nUnderstand what symptoms infected systems may present, so that Threat Hunters and Incident Handlers can know\r\nhow to identify such behavior;\r\nDevelop Yara and Sigma Detection Rules (if possible).\r\nExecution Flow Summary: From Loader to IcedID\r\nBelow is an illustrated and summarized way of how this IcedID sample infects the victim system.\r\nThe great techevo, posted a trilogy of research, in which he has been analyzing the infection chain of this version of the\r\nIcedID campaign. This research is about the 2nd Stage DLL that is injected into a svchost.exe process running. In this\r\nresearch we will analyze what it does, how it does it, and how we can detect it from the execution of the loader (r.dll).\r\nReverse Engineering: IcedID DLL version of x64\r\nThis x64 version of IcedID (unlike the IcedID I reviewed previously) is very lightweight and contains few instructions. So\r\nlight and small that it allows us to take a printout of its entire function call tree. Therefore, we will go through each function,\r\nbut detailing only those that contain important features.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 1 of 14\n\nThe body of the main function allows us to have a general idea of the features implemented in this version of IcedID. Below\r\nyou can see a decryption function, followed by functions relating to configuring communication with the C\u0026C servers, and\r\na possible drop feature from a possible 3rd Stager.\r\nNOTE\r\nIt is worth remembering that most of the variable and function names were renamed by me, with the aim of\r\nimproving understanding of the analysis.\r\nThe first function we will look at will be a decryption function. This function is essential for the Yara signature development\r\nprocess, and for the development of the configuration extractor. Let’s analyze it.\r\nConfiguration Decryption\r\nIt is interesting to see, that IcedID has changed its way of decrypting configuration. In my previous research, IcedID\r\nimplemented the RC4 algorithm, to decrypt the configuration in which the key and data were found, in the .data section.\r\nIn the image below, you can see that the data location section was changed to the .d section, in addition to a relatively simple\r\ncustom decryption algorithm being implemented.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 2 of 14\n\nSimply put, the algorithm is executed 32 times in a do while loop. While this do while loop executes, the counter will be\r\nincremented and its value will be used to indicate the position where the keystream should concatenate a slice of data, with\r\nthe entire block of data.\r\nThe XOR operation will then select the first byte of the keystream and the byte at the address keystream[0x40], an XOR\r\noperation is performed on these two bytes, where the result of this operation will be the decrypted byte.\r\nThe decrypted byte will be placed in a specific position. Thus, in the end, all necessary bytes will be decrypted within the\r\nwhile loop, 32 times.\r\nBelow is my Python implementation of the algorithm identified above.\r\ndef decrypt(data, key):\r\n counter = 0\r\n output = bytearray(len(data))\r\n while counter \u003c 0x20:\r\n keystream = data[counter:] + key\r\n byte_decrypted = keystream[0x40] ^ keystream[0]\r\n output[counter + 0x40 - len(key)] = byte_decrypted\r\n counter += 1\r\n return output\r\ndata = bytearray.fromhex(\"1b38485fc0de252da5a3f23ebcbbed3eec16599b1bfba95915b021c90ee465dd0fefecd17766388d6cc6849683742781\r\nkey = bytearray.fromhex(\"1b38485fc0de252da5a3f23ebcbbed3eec16599b1bfba95915b021c90ee465dd0fefecd17766388d6cc68496837427816\r\ndecrypted_data = decrypt(data, key)\r\nprint(\"\\nConfig Decrypted in Hex:\", decrypted_data.hex())\r\nprint(\"Config Decrypted in ASCII:\", decrypted_data.decode(\"ascii\", errors=\"ignore\"))\r\nAnd below, the output generated was the C\u0026C hostname of this IcedID campaign.\r\nConfig Decrypted in Hex: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\r\nConfig Decrypted in ASCII: Bpodiumstrtss.comk?\r\nLet’s move on to the next function to be executed in the main function, botnet_info_struct.\r\nIcedID’s Botnet Information Struct\r\nThis function is interesting, as it involves collecting information from the user and the infected system, to build the Cookies\r\nheader, which will be sent to the C\u0026C server. Below we can see its code structure in Assembly.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 3 of 14\n\nThrough pseudo code, we can have a better understanding of the position of each information, starting with the __gads\r\nparameter. This parameter will contain the campaign ID and previous information about the system.\r\nAnalyzing the os_version function, we are presented with the collection of the version and build of the infected Windows\r\nseparated by a dot, which will be concatenated to the _gat parameter.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 4 of 14\n\nIn the following function, we are presented with the take_cpu_info function. This function collects information from the\r\ninfected system’s CPU, and concatenates it into the _ga parameter. Information is collected by executing the take_cpu_info\r\nfunction, which implements the execution of _cpuid and _rdtsc. Both pieces of information are separated by a period.\r\nMoving on to the next function, we arrive at the local_enumeration function. In which, it collects information from the user\r\nand the infected device. The _u parameter will contain username and hostname information. In the __io parameter, it will\r\ncontain the user’s SID.\r\nAnd finally, take_adptersinfo_gid is executed, the last function to build the botnet’s information structure. This function\r\nwill collect information from the infected system’s network adapter, and will perform manipulation of the MAC address\r\ninformation, and concatenate the output into the _gid parameter.\r\nC\u0026C Communication Setup\r\nThe next function is the configuration and execution of the connection with the C\u0026C servers, the\r\nconditionals_to_c2connection. This function calls a wrapper function that will actually take the code flow to the\r\nWinHTTP standard API execution function, to execute a connection through the HTTP protocol. The return of this\r\nfunction will be conditioned and depending on its content, the code may execute the process_xor_memory_region\r\nfunction. In which, it performs exactly what the name indicates.\r\nThe main function has no particularity (http_connection function), as its intentions are very clear, just reading the full use\r\nof WinHTTP functions is enough.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 5 of 14\n\nPossible Dropped File’s Location – 3nd Stage\r\nAfter communicating with the C\u0026C servers, IcedID demonstrates the ability to drop a possible 3rd Stage onto disk. It is\r\npossible to observe this capacity by analyzing the create_write_file_mem_alloc function.\r\nAnalyzing the first function to be executed within create_write_file_mem_alloc, programdata_create_write_file\r\nfunction, we are able to observe that the directory in which the 3rd stage would be saved would be in the C:\\ProgramData\\\r\ndirectory.\r\nNext, the programdata_create_write_file function will execute the create_write_file function. This is the function that\r\nactually creates and writes the 3rd stage to disk.\r\nDepending on the conditional to be followed in the create_write_file_mem_alloc function, the code can follow the flow\r\nand execute the gettemppath_w_create_write_file function. This function collects the system’s default temporary directory\r\nvia the GetTempPathA API and then executes an interesting function.\r\nThis function is pe_header_verification. This function appears to check whether the 3rd stage is in fact a PE file, through\r\nsome calculations the code hopes to obtain the location and mapping of the MZ and PE headers (mapping occurs in the\r\nmapping_pe function). Where, if an MZ and PE header is not identified, the return code will be 0 (failure), if the headers\r\ncan be identified, the return code will be 1 (success).\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 6 of 14\n\nInfected System Behavior Analysis: Threat Hunting and Incident Handler\r\nNow that we have analyzed and know the capabilities of this lightweight x64 DLL version of IcedID, in this section we will\r\nanalyze what patterns are produced when running it in an environment controlled and monitored by us.\r\nThis analysis will produce rich intelligence for Threat Hunters and Incident Handlers, who will be able to identify the\r\nbehavior produced by running this version of IcedID throughout their operations, in infrastructures monitored by a SIEM\r\nand receiving logs from Sysmon.\r\nFor this analysis to be effective, it is necessary to run the DLL Loader (which techevo analyzed in part 3 of its triology)\r\nthrough rundll32, executing the vcab function with the /k argument and the password that is characteristic of each\r\ncampaign.\r\nWhen running the loader, below it is possible to observe its execution (with function names and arguments characteristic of\r\nthis version of IcedID) through the Sysmon Event ID 1 process creation audit log, followed by a DNS resolution to the\r\nC\u0026C hostname of this sample (detected by Sysmon Event ID 22) through a running svchost process.\r\nNOTE\r\nThe next event can be Sysmon Event ID 22 or Sysmon Event ID 3, depending on whether the hostname is still\r\nresponding to connections.\r\nAs we know, the loader will decrypt the IcedID DLL version in memory, and inject it into a running svchost process.\r\nTherefore, when looking for this behavior in systems through a SIEM, the connection to the C\u0026C servers will be executed\r\nby a benign process (but with malicious code injected) from svchost.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 7 of 14\n\nIf Threat Hunters or Incident Handlers have the opportunity to analyze the execution window traffic, they can also validate\r\nthe malware family through the characteristics of the communication process with the IcedID C\u0026C.\r\nAs we discussed in the reverse engineering section, IcedID will collect user and host information, and send it through\r\nspecific parameters in the Cookie header.\r\nTo better understand what is being sent to the C\u0026C, below is the list of parameters and assigned information.\r\n{\r\n \"__gads\" : \"botnet_campaing_info\",\r\n \"_gat\" : \"windows_version_build\",\r\n \"_ga\" : \"cpu_info\",\r\n \"_u\" : \"username_hostname_info\",\r\n \"__io\" : \"user_sid\",\r\n \"_gid\" : \"mac_info\"\r\n}\r\nDetection Engineering: SIEM Detection Rule (ELK)\r\nNow that we better understand the symptoms produced by an infection from this strain of IcedID, we will be able to\r\nproduce a detection rule for SIEM, with the aim of detecting possible infections originating from this strain of IcedID.\r\nBelow is a correlation rule in EQL syntax, which detects the sequence of observed events characteristic of this version of\r\nIcedID.\r\nsequence by host.name with maxspan=60s\r\n[any where (event.code : \"1\" or event.code: \"4688\") and process.name : \"rundll32.exe\" and (process.command_line : \"*vcab*\"\r\n[any where (event.code : \"22\" or event.code: \"3\") and process.name: \"svchost.exe\"]\r\nBelow is the fully configured detection rule.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 8 of 14\n\nDetection Engineering: SIEM Detection Rule Match (Elastic)\r\nAnd in order to validate the functionality of this rule, I ran the IcedID loader again in my controlled and monitored\r\nenvironment. And as you can see in the image below, the detection rule was effective in detecting the execution of this\r\nversion of IcedID.\r\nBelow, we can see in more detail the flow of events that led to the detection rule matching. Having exactly the same pattern\r\nof behavior observed previously.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 9 of 14\n\nDetection Engineering: Yara Rule\r\nNow that we have analyzed how this version of IcedID performs its capabilities, and identified its particularities, we must\r\ndevelop a Yara rule to help Threat Hunters and Incident Handlers detect possible samples of IcedID in their infrastructures.\r\nYara rules also allow us to identify possible new versions with small modifications, but in which our Yara rule still consists\r\nof detecting them. If the malware family produces a sample that your Yara rule cannot detect, it is because there have been\r\nsignificant changes in its development. And so, you can track changes in malware families over time.\r\nAs we analyzed, there are two functions that are very characteristic of this version of IcedID, they are:\r\nThe function of the Configuration Decryption Algorithm;\r\nThe function of Building the Structure of Botnet Information to be sent to C\u0026C.\r\nTherefore, Yara rule was based on these two characteristic functions.\r\nrule icedid_x64dll_stager {\r\n meta:\r\n author = \"0x0d4y\"\r\n description = \"This rule detects samples from the IcedID family unpacked in memory, identifying code reuse of new co\r\n date = \"2024-04-08\"\r\n score = 100\r\n reference = \"https://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\"\r\n yarahub_reference_md5 = \"06cc2fdfd408c15a1e16adfb46e8bb38\"\r\n yarahub_uuid = \"5e3bb39f-f9c8-4eb5-8cfd-6812bb27b74a\"\r\n yarahub_license = \"CC BY 4.0\"\r\n yarahub_rule_matching_tlp = \"TLP:WHITE\"\r\n yarahub_rule_sharing_tlp = \"TLP:WHITE\"\r\n malpedia_family = \"win.icedid\"\r\n strings:\r\n $conf_decrypt_algorithm = {\r\n 45 33 C0 ?? ?? ?? ?? ?? ?? ?? 49 2B C9 4B 8D 14 08 49 FF C0 8A 42 40 32 02 88 44 11 40 49 83 F8 20\r\n }\r\n $botnet_info_struct_build = {\r\n 44 8B CB 4C 8D 05 ?? ?? ?? ?? 48 8D ?? ?? ?? ?? ?? 48 8B CF FF 15 ?? ?? ?? ?? 48 63 D8 44 8B CD 48 8D 15 ?? ?? ??\r\n }\r\n condition:\r\n uint16(0) == 0x5a4d and\r\n ($conf_decrypt_algorithm or $botnet_info_struct_build)\r\n}\r\nDetection Engineering: Yara Rule Matches\r\nIn order to validate the good functionality of the Yara rule, I submitted the rule on two platforms that allow scanning your\r\nYara rule on a large set of malware samples (and benign software, to test for false positives). Unpac.me and the Yara Scan\r\nService that sends the results in json format to your email.\r\nBelow, we can see the result on the unpac.me platform.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 10 of 14\n\nAnd below, we can see the output sent to me, of all the samples that matched my Yara rule, through the Yara Scan Service.\r\n[\r\n {\r\n \"rule\": \"icedid_x64dll_stager\",\r\n \"malware\": \"IcedID\",\r\n \"sha256\": \"96e2e63b51500cff2f266e0e4894a667b11d47245837bcb797b8899e04b16b8a\",\r\n \"mime_type\": \"application\\/x-msdownload\",\r\n \"virustotal_link\": \"https:\\/\\/www.virustotal.com\\/gui\\/file\\/96e2e63b51500cff2f266e0e4894a667b11d47245837bcb797b88\r\n \"malwarebazaar_link\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/96e2e63b51500cff2f266e0e4894a667b11d47245837bcb797b8899e\r\n \"tags\": []\r\n },\r\n {\r\n \"rule\": \"icedid_x64dll_stager\",\r\n \"malware\": \"IcedID\",\r\n \"sha256\": \"63770070208c532df8a7d41a391faff7c5280814bebd13b0b935f0fa80fc8e27\",\r\n \"mime_type\": \"application\\/x-msdownload\",\r\n \"virustotal_link\": \"https:\\/\\/www.virustotal.com\\/gui\\/file\\/63770070208c532df8a7d41a391faff7c5280814bebd13b0b935f\r\n \"malwarebazaar_link\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/63770070208c532df8a7d41a391faff7c5280814bebd13b0b935f0fa\r\n \"tags\": []\r\n },\r\n {\r\n \"rule\": \"icedid_x64dll_stager\",\r\n \"malware\": \"IcedID\",\r\n \"sha256\": \"2fa82bdf1836fc7f61d09637580ca0ea26f3aed7e59acad9cd7f793148368214\",\r\n \"mime_type\": \"application\\/x-msdownload\",\r\n \"virustotal_link\": \"https:\\/\\/www.virustotal.com\\/gui\\/file\\/2fa82bdf1836fc7f61d09637580ca0ea26f3aed7e59acad9cd7f7\r\n \"malwarebazaar_link\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/2fa82bdf1836fc7f61d09637580ca0ea26f3aed7e59acad9cd7f7931\r\n \"tags\": []\r\n },\r\n {\r\n \"rule\": \"icedid_x64dll_stager\",\r\n \"malware\": \"IcedID\",\r\n \"sha256\": \"42605a1640895ba3d64833f8fc077c074710b142fcb0332607af8560feb64a24\",\r\n \"mime_type\": \"application\\/x-msdownload\",\r\n \"virustotal_link\": \"https:\\/\\/www.virustotal.com\\/gui\\/file\\/42605a1640895ba3d64833f8fc077c074710b142fcb0332607af8\r\n \"malwarebazaar_link\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/42605a1640895ba3d64833f8fc077c074710b142fcb0332607af8560\r\n \"tags\": []\r\n },\r\n {\r\n \"rule\": \"icedid_x64dll_stager\",\r\n \"malware\": \"IcedID\",\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 11 of 14\n\n\"sha256\": \"8cbd6dee1613f15d998328021a90ecf13b092ea0312555ae4b5627e8f758fe97\",\r\n \"mime_type\": \"application\\/x-msdownload\",\r\n \"virustotal_link\": \"https:\\/\\/www.virustotal.com\\/gui\\/file\\/8cbd6dee1613f15d998328021a90ecf13b092ea0312555ae4b562\r\n \"malwarebazaar_link\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/8cbd6dee1613f15d998328021a90ecf13b092ea0312555ae4b5627e8\r\n \"tags\": []\r\n },\r\n {\r\n \"rule\": \"icedid_x64dll_stager\",\r\n \"malware\": \"IcedID\",\r\n \"sha256\": \"b3063a902d1acc5bdafb98a7976974ea2430b8d62d8aeb414cc3f2fab190dafa\",\r\n \"mime_type\": \"application\\/x-msdownload\",\r\n \"virustotal_link\": \"https:\\/\\/www.virustotal.com\\/gui\\/file\\/b3063a902d1acc5bdafb98a7976974ea2430b8d62d8aeb414cc3f\r\n \"malwarebazaar_link\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/b3063a902d1acc5bdafb98a7976974ea2430b8d62d8aeb414cc3f2fa\r\n \"tags\": []\r\n },\r\n {\r\n \"rule\": \"icedid_x64dll_stager\",\r\n \"malware\": \"UNKNOWN\",\r\n \"sha256\": \"376074f492525537909adb586df6454950e8424665ef9ece63c9ea90979bb238\",\r\n \"mime_type\": \"application\\/x-msdownload\",\r\n \"virustotal_link\": \"https:\\/\\/www.virustotal.com\\/gui\\/file\\/376074f492525537909adb586df6454950e8424665ef9ece63c9e\r\n \"malwarebazaar_link\": \"https:\\/\\/bazaar.abuse.ch\\/sample\\/376074f492525537909adb586df6454950e8424665ef9ece63c9ea90\r\n \"tags\": []\r\n }\r\n]\r\nYou can go to each malwarebaazar link and check the samples.\r\nDetection Engineering: Suricata Rule\r\nBecause we also analyze the traffic produced by running this version of IcedID, we are also able to produce a detection for\r\nthe pattern of this malicious traffic. Below is the Suricata rule that I developed.\r\nalert http any any -\u003e any any (msg:\"IcedID x64 DLL Traffic was Detected\";http.cookie;content:\"__gads=\";startswith;classty\r\nDetection Engineering: Suricata Rule Validation\r\nIn order to validate the detection capacity of this signature, below is a PoC of the infection process and detection of traffic\r\nproduced by IcedID.\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 12 of 14\n\nx64 DLL IcedID’s Configuration Extractor\r\nAnd the last output that we can generate to extract as much intelligence as possible from the analysis of this sample, let’s\r\nmove on to creating the Configuration Extractor.\r\nWe have already analyzed the configuration decryption algorithm for this IcedID sample, and we just need to automate the\r\nconfiguration extraction process for the other samples that can be tested. I used my personal project, OCEK, to reuse a\r\nPython code that collects the raw data in a certain PE section.\r\nBelow is the source code of my configuration extractor, for this version of IcedID.\r\nimport sys\r\nsys.path.append('/home/researcher/Projects/OCEK') # \u003c- My project to automate some config extractor's code\r\nfrom helpers.get_pe_section import get_pe_section\r\n0:00 / 0:29\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 13 of 14\n\ndef decrypt(data, key):\r\n counter = 0\r\n output = bytearray(len(data))\r\n while counter \u003c 0x20:\r\n keystream = data[counter:] + key\r\n byte_decrypted = keystream[0x40] ^ keystream[0]\r\n output[counter + 0x40 - len(key)] = byte_decrypted\r\n counter += 1\r\n return output\r\nfilepath = input(\"\\nPut the IcedID x64 DLL filepath: \")\r\ndata = input(\"Put the PE section: \")\r\npayload = get_pe_section(filepath, data)\r\ndecrypted_data = decrypt(payload, payload)\r\nprint(\"\\nHex Input Decrypted:\", decrypted_data.hex())\r\nprint(\"ASCII Output Decrypted:\", decrypted_data.decode(\"ascii\", errors=\"ignore\"))\r\nprint(\"\")\r\nConclusion\r\nWhen we reached the end of this research, we were able to analyze the sample statically, run it in a monitored and controlled\r\nlaboratory, and through this analysis we were able to extract intelligence in different formats:\r\nDetection Rule for SIEM;\r\nYara Detection Rule;\r\nSuricata Detection Rule.\r\nI hope you, the reader, had fun and/or learned something new. To the next!\r\nReferences\r\n1. Technical Evolution’s Blog\r\n2. Suricata’s Blog\r\n3. Suricata Rule\r\nSource: https://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nhttps://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/\r\nPage 14 of 14",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://0x0d4y.blog/icedid-technical-analysis-of-x64-dll-version/"
	],
	"report_names": [
		"icedid-technical-analysis-of-x64-dll-version"
	],
	"threat_actors": [],
	"ts_created_at": 1775434934,
	"ts_updated_at": 1775791227,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/caae5d01e3fab72661d45cb29423bd64e16e32d9.pdf",
		"text": "https://archive.orkl.eu/caae5d01e3fab72661d45cb29423bd64e16e32d9.txt",
		"img": "https://archive.orkl.eu/caae5d01e3fab72661d45cb29423bd64e16e32d9.jpg"
	}
}