{
	"id": "6f77669e-9d2d-4d64-a298-88f66fbc969b",
	"created_at": "2026-04-06T03:37:18.056119Z",
	"updated_at": "2026-04-10T03:21:11.672662Z",
	"deleted_at": null,
	"sha1_hash": "e5a62dc2b8ba63589fb6da3ea94681f07a3b7679",
	"title": "Covert Channels and Poor Decisions: The Tale of DNSMessenger",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2286662,
	"plain_text": "Covert Channels and Poor Decisions: The Tale of DNSMessenger\r\nBy Edmund Brumaghin\r\nPublished: 2017-03-02 · Archived: 2026-04-06 03:34:43 UTC\r\nThis post was authored by Edmund Brumaghin and Colin Grady\r\nExecutive Summary\r\nThe Domain Name System (DNS) is one of the most commonly used Internet application protocols on corporate\r\nnetworks. It is responsible for providing name resolution so that network resources can be accessed by name,\r\nrather than requiring users to memorize IP addresses. While many organizations implement strict egress filtering\r\nas it pertains to web traffic, firewall rules, etc. many have less stringent controls in place to protect against DNS\r\nbased threats. Attackers have recognized this and commonly encapsulate different network protocols within DNS\r\nto evade security devices.\r\nTypically this use of DNS is related to the exfiltration of information. Talos recently analyzed an interesting\r\nmalware sample that made use of DNS TXT record queries and responses to create a bidirectional Command and\r\nControl (C2) channel. This allows the attacker to use DNS communications to submit new commands to be run on\r\ninfected machines and return the results of the command execution to the attacker. This is an extremely\r\nuncommon and evasive way of administering a RAT. The use of multiple stages of Powershell with various stages\r\nbeing completely fileless indicates an attacker who has taken significant measures to avoid detection.\r\nIronically, the author of the malware called SourceFire out in the malware code itself shortly after we released\r\nCisco Umbrella, a security product specifically designed to protect organizations from DNS and web based threats\r\nas described here.\r\nDetails\r\nWhat initially drew our interest to this particular malware sample was a tweet published by security researcher on\r\nTwitter (thanks simpo!) regarding a Powershell script that he was analyzing that contained the base64 encoded\r\nstring 'SourceFireSux'. Interestingly enough, Sourcefire was the only security vendor directly referenced in the\r\nPowershell script. We searched for the base64 encoded value\r\n'UwBvAHUAcgBjAGUARgBpAHIAZQBTAHUAeAA=' which was referenced in the tweet, and were able to\r\nidentify a sample that had been uploaded to the public malware analysis sandbox, Hybrid Analysis. Additionally,\r\nwhen we searched for the decoded string value we found a single search engine result that pointed to a Pastebin\r\npage. The hash listed in the Pastebin led us to a malicious Word document that had also been uploaded to a public\r\nsandbox. The Word document initiated the same multiple-stage infection process as the file from the Hybrid\r\nAnalysis report we previously discovered and allowed us to reconstruct a more complete infection process.\r\nAnalyzing our telemetry data, we were ultimately able to identify additional samples, which are listed in the\r\nIndicators of Compromise section of this post.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 1 of 17\n\nAs a security vendor, we know that we are doing something right when malware authors begin to specifically\r\nreference us within their malware. Naturally we decided to take a closer look at this particular sample.\r\nIn this particular case, we began by analyzing the Powershell file that had been incorrectly submitted to the public\r\nsandbox as a VBScript file, which we are now referring to as 'Stage 3'. It turns out the string referenced earlier is\r\nused as a mutex, as you can see in the deobfuscated Powershell below in Figure 1.\r\nFigure 1: Mutex Creation\r\nStage 1 Malicious Word Document\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 2 of 17\n\nAs previously mentioned, we identified the source of this infection chain, which was a malicious Microsoft Word\r\ndocument that was delivered to the victim via a phishing email message. Interestingly, the Word document was\r\nmade to appear as if it were associated with a secure email service that is secured by McAfee. This is likely an\r\neffective way to increase the odds of the victim opening the file and enabling macros as McAfee is a well known\r\nsecurity vendor and likely immediately trusted by the victim. The document informs the user that it is secured and\r\ninstructs the user to enable content.\r\nFigure 2: Malicious Word Document \r\nThe document uses the Document_Open() function to call another VBA function. The called function sets a long\r\nstring that defines a Powershell command and includes the code to be executed. The command is then executed\r\nusing the Windows Management Interface (WMI) Win32_Process object using the Create method.\r\nThe code that is passed to Powershell via the command line is mostly Base64 encoded and compressed using gzip,\r\nwith a small portion at the end that is not encoded which is then used to unpack the code and pass it to the Invoke-Expression Powershell cmdlet (IEX) for execution. This allows the code to be executed without ever requiring it\r\nto be written to the filesystem of the infected system. Overall, this is pretty typical for malicious Word documents\r\nthat we see being distributed in the wild. We noted that while there is a VBA stream that references a download\r\nfrom Pastebin, the samples we analyzed did not appear to make use of this functionality.\r\nWe also observed that the AV detection on this particular sample was fairly low (6/54) and that ClamAV was able\r\nto successfully detect this particular sample.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 3 of 17\n\nFigure 3: VirusTotal Results\r\nStage 2 Powershell\r\nThe execution of the Powershell that is passed to IEX by the Stage 1 Word document is where we begin to observe\r\nseveral interesting activities occurring on an infected system. A function at the end of the Powershell script\r\ndescribed in Stage 1 defines the actions for Stage 2 as well as characteristics related to Stage 3.The code in Stage 2\r\nhas been obfuscated, and we will refer to the main function used by this stage as 'pre_logic' as the main function\r\nused by Stage 3 is referenced as 'logic'.\r\nThe 'pre_logic' function present in this stage supports two switches. One is used to determine whether or not to\r\nachieve persistence for the next stage of the infection process on the target system. If persistence is selected the\r\nother switch defines whether or not the Stage 3 code should be executed once it is staged.\r\nFigure 4: Deobfuscated 'pre-logic' Function \r\nIn addition to these two switches, the 'pre_logic' function also supports four parameters which are subsequently\r\npassed to the 'logic' function in the next stage of the infection process. These parameters are used to determine\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 4 of 17\n\nwhat subdomains to use when sending DNS TXT record queries in the next stage of the infection process.\r\nThe function then unpacks the Powershell that will be used during the next (Stage 3) stage from a base64 encoded\r\nblob located within the Powershell script itself. It also defines some of the code which will be used later, including\r\nthe function call and parameters to use when executing the next stage of the infection.\r\nIf the option to achieve persistence was selected when the 'pre_logic' function was called, the function will then\r\nquery the infected system to determine how to best achieve persistence. Depending on the access rights of the user\r\naccount within which the malware is operating, the malware will then query registry paths that are commonly\r\nused by malware to achieve persistence.\r\nIf operating under an account with Administrator access to the system the script will query and set:\r\n$reg_win_path: \"HKLM:Software\\Microsoft\\Windows\\CurrentVersion\"\r\n$reg_run_path: \"HKLM:Software\\Microsoft\\Windows\\CurrentVersion\\Run\\\"  \r\nIf operating under a normal user account, the script will query and set:\r\n$reg_win_path: \"HKCU:Software\\Microsoft\\Windows\"\r\n$reg_run_path: \"HKCU:Software\\Microsoft\\Windows\\CurrentVersion\\Run\\\"\r\nFigure 5: Registry Activity \r\nThe script then determines the version of Powershell that is being used on the infected system. If the infected\r\nsystem is using Powershell 3.0 or later, the decoded Stage 3 payload is written to an Alternate Data Stream (ADS)\r\nlocated at '%PROGRAMDATA%\\Windows\\' and named 'kernel32.dll'.\r\nIf the system is running an earlier version of Powershell, the Stage 3 payload is encoded and written to the registry\r\nlocation dictated by the assignment of $reg_win_path earlier with the key name of 'kernel32'. The code to unpack\r\nand execute the Stage 3 payload is also later written to the registry location of $reg_win_path with the key name\r\nof 'Part'.\r\nFigure 6: PS Check \u0026 Persistence \r\nOnce this has completed, the script will again check to determine the access level of the user running the malware.\r\nIf the malware has been executed with Administrator permissions, the WMI event subscriptions for '_eventFilter',\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 5 of 17\n\n'CommandLineEventConsumer', and '_filtertoconsumerbinding' will be removed from the infected system. The\r\nmalware then establishes its own permanent WMI event subscription, filtered for 'Win32_LogonSession' events\r\nand tied to 'CommandLineEventConsumer'. This is what is used to read and execute the Stage 3 payload that was\r\npreviously stored in the ADS whenever a new logon session is created on the infected system. This is essentially\r\nthe WMI equivalent of a registry-based run key from a persistence perspective. The Stage 3 malware is by default\r\nset to run 'onidle' after 30 minutes. If the switch associated with the execution of Stage 3 was passed to the\r\n'pre_logic' function at the beginning of this stage, the Stage 3 payload will then be executed immediately.\r\nFigure 7: Persistence Mechanism \r\nAs seen above, the malware also creates a Scheduled Task on the infected system named \"kernel32\" which is\r\nassociated with the Stage 3 payload that was stored in the ADS or registry depending on the version of powershell\r\nrunning on the infected system. In analyzing other samples associated with this campaign, we observed that the\r\nscheduled task may change across samples.\r\nStage 3 Powershell\r\nThe Stage 3 powershell that is executed by Stage 2 of this infection process was obfuscated primarily through the\r\nuse of obtuse function and variable names (e.g. ${script:/==\\/\\/\\/==\\__/==} instead of $domains). Base64 string\r\nencoding was also present throughout the script. Once we deobfuscated it, we found that the script contained a\r\nlarge array of hard coded domain names, with one of them being randomly selected and used for subsequent DNS\r\nqueries. It is important to note that while the Powershell scripts for stages 3 and 4 contain two arrays of domains,\r\nthe first array is only used if a failure condition is reached while the sample is using the second array.\r\nFigure 8: Stage 3 Domain List\r\nThe 'logic' function present within this Powershell script randomly selects a C2 domain from the second array in\r\nthe script and uses this domain to perform an initial lookup. If the result of the initial DNS TXT record request is\r\nempty or in the case the lookup fails, the 'do_lookup' function is then called and randomly selects a domain from\r\nthe first array in the script. Interestingly, the domains used by the 'do_lookup' function did not appear to have\r\nactive 'www' or 'mail' TXT records.\r\nThe script also uses specific subdomains which are combined with the domains and used for the initial DNS TXT\r\nrecord queries performed by the malware. The malware uses the contents of the TXT record in the response to\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 6 of 17\n\nthese queries to determine what action to take next. For instance, the first subdomain is 'www' and a query\r\nresponse with a TXT record containing 'www' will instruct the script to proceed. Other actions that may be taken\r\nare 'idle' and 'stop'.\r\nFigure 9: Stage 3 Command Processing \r\nOnce the initial DNS response is received by the malware, it then iterates to the next subdomain which is 'mail'.\r\nThe malware uses this domain in another DNS TXT record query to attempt to retrieve the Stage 4 payload\r\nassociated with this infection process. The response to this DNS request results in the transmission of the fourth\r\nstage malware, stored within the TXT record as displayed in Figures 10 and 11. Due to the size of the Stage 4\r\npayload, DNS makes use of TCP for this transaction.\r\nFigure 10: Response Containing Stage 4 Payload \r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 7 of 17\n\nAnother view showing the Wireshark interpretation of the DNS protocol and packet payload is below.\r\nFigure 11: Alternate View of Stage 4 Payload\r\nThe code associated with this fourth stage is then cleaned and passed into the Invoke-Expression Powershell\r\ncmdlet (IEX) and executed within the context of the third stage process. The fourth stage payload is not\r\nautonomous and simply attempting to execute the fourth payload itself will fail, as it relies upon a decode function\r\npresent within the third stage Powershell script.\r\nFigure 12: Stage 3 Decode Function \r\nThis function is responsible for a couple of different operations. It takes the code received in the DNS query\r\nresponse and defines a string variable which contains the code. It then calls the decode function from the third\r\nstage and passes the decoded string into IEX to further extend the Powershell environment. Once this is complete,\r\nit then calls a function in the newly extended environment to execute the fourth stage code along with specific\r\nparameters. These parameters include the fourth stage C2 domain to use as well as the program to execute which\r\nin this case is the Windows Command Line Processor (cmd.exe). This is interesting because it results in the fourth\r\nstage payload never actually being written to the filesystem of the infected system.\r\nStage 4 Powershell\r\nAs described above, the Stage 4 Powershell payload is decoded by the 'dec' function present within Stage 3. At the\r\nend of the Stage 4 payload is a call to the 'cotte' function, present in the decoded Stage 4 code, which provides\r\nadditional parameters including the C2 domain to use as well as the program to execute (cmd.exe). When the\r\nfunction executes cmd.exe it redirects STDIN, STDOUT, and STDERR to allow the payload to read from and\r\nwrite to the command line processor.\r\nThe domain provided to the function call is then used to generate the DNS queries used for the main C2\r\noperations. Just like in the Stage 3 Powershell script, the Stage 4 payload also contains two arrays of hard coded\r\ndomains, but this stage only appears to make use of the second array.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 8 of 17\n\nFigure 13: Stage 4 Domain List \r\nEvery 301st DNS response from main C2 server, the sample sends a separate DNS TXT resolution request to a\r\ndomain taken from the array described above using the Get-Random cmdlet. This secondary C2 request is to\r\ndetermine whether the malware should continue to run on the infected system. Similar to what we saw with the\r\nStage 3 Powershell script, this request is made to the 'web' subdomain of the secondary C2 domain.\r\nFigure 14: Stage 4 Secondary C2 Domain Generation \r\nIf the secondary C2 server returns a TXT record that contains the string 'stop', the malware will cease operations.\r\nFigure 15: Stage 4 Stop Command \r\nThe main C2 channel itself is established through the transmission of a \"SYN\" message from the infected system\r\nto the main C2 server.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 9 of 17\n\nFigure 16: Example Stage 4 'SYN' Message Response \r\nOnce this is completed, the STDOUT and STDERR output that was captured from the Windows Command Line\r\nprocessor earlier in Stage 4 is transmitted using a \"MSG\" message. This allows the attacker to send commands to\r\nbe executed directly by the Command Processor and receive the output of those commands all using DNS TXT\r\nrequests and responses. This communication is described in greater detail in the following section. Below is the\r\nDNS analysis and contents of the query request send from an infected system to the C2 server.\r\nFigure 17: Example 'MSG' Message\r\nThe query domain structure is obfuscated. If we take the DNS request query and run it through a decoding\r\nfunction, we can clearly see that it is the output of the Windows Command Line Processor being sent to the C2\r\nserver.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 10 of 17\n\nFigure 18: Decoded TXT Request \r\nThis clearly illustrates the establishment of an interactive C2 channel that can be used to execute system\r\ncommands as well as receive the output of those commands.\r\nCommand and Control (C2) Communications\r\nThe C2 domains associated with the infection chain from the malicious Word document were initially registered\r\non 2017-02-08. The domains associated with the Powershell sample that we analyzed from Hybrid Analysis were\r\ninitially registered on 2017-02-18. Several of the domains were registered by a registrant account using the\r\nfollowing email address:\r\nvaleriy[.]pagosyan[@]yandex[.]com\r\nThe remaining domains were registered using the NameCheap proxy registration service.\r\nAccording to data available within Umbrella, the majority of DNS activity related to the domains used by the\r\npowershell sample appears to have occurred between 2017-02-22 and 2017-02-25. There was less activity\r\nassociated with the other identified sample, with most occurring on 2017-02-11.\r\nFigure 19: Sample DNS Traffic Graph\r\nAll C2 communications associated with this malware are performed using DNS TXT queries and responses. The\r\ninteractive 'MSG' queries require the successful establishment of a C2 communications channel via the use of the\r\nprerequisite 'SYN' query. The messages consist of the following elements:\r\n$session_id - A four digit number that is initially generated by infected machines. It never changes and is included\r\nin all subsequent DNS queries and responses.\r\n$sequence_num - A four digit number that is initially generated by infected machines. It changes periodically\r\nduring C2 communications and the new value must be included in the next query.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 11 of 17\n\n$acknowledgement_num - A four digit number that is set by the response to the 'SYN' message. This value does\r\nnot appear to change and must be included in all subsequent 'MSG' queries.\r\nBytes 5 and 6 of the DNS queries and responses determine the message type and can be any of the following\r\nvalues:\r\n00 - 'SYN' message\r\n01 - 'MSG' message\r\n02 - 'FIN' message\r\nThe 'MSG' queries which are used to send commands to execute and return the output of the executed commands\r\nare hex-encoded and use a dot separator after every 30 bytes.\r\nThe following diagram illustrates the overall flow of the C2 communications. Note that during C2, there may be\r\nseveral 'MSG' queries and responses depending on what the attacker is attempting to execute on an infected host.\r\nFigure 20: C2 Traffic Flow \r\nBelow is a diagram illustrating how the different messages and associated responses are formed.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 12 of 17\n\nFigure 21: C2 Message Structure \r\nConclusion\r\nThis malware sample is a great example of the length attackers are willing to go to stay undetected while\r\noperating within the environments that they are targeting. It also illustrates the importance that in addition to\r\ninspecting and filtering network protocols such as HTTP/HTTPS, SMTP/POP3, etc. DNS traffic within corporate\r\nnetworks should also be considered a channel that an attacker can use to implement a fully functional,\r\nbidirectional C2 infrastructure. Cisco Umbrella is a product that can be used specifically for this purpose. In\r\naddition to stopping this particular attack, DNS monitoring and filtering can also disrupt a large portion of overall\r\nmalware infections, as the over 90% of malware makes use of the DNS network protocol at some stage of the\r\ninfection or post-infection process.\r\nCoverage\r\nAdditional ways our customers can detect and block this threat are listed below.\r\nAdvanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these\r\nthreat actors.\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 13 of 17\n\nCWS orWSA web scanning prevents access to malicious websites and detects malware used in these attacks.\r\nEmail Security can block malicious emails sent by threat actors as part of their campaign.\r\nThe Network Security protection ofIPSandNGFW have up-to-date signatures to detect malicious network activity\r\nby threat actors.\r\nAMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.\r\nUmbrella prevents DNS resolution of the domains associated with malicious activity.\r\nIndicators of Compromise (IOC)\r\nBelow are indicators of compromise that can be used to identify the attack described in this post.\r\nHashes:\r\nf9e54609f1f4136da71dbab8f57c2e68e84bcdc32a58cc12ad5f86334ac0eacf (SHA256)\r\nf82baa39ba44d9b356eb5d904917ad36446083f29dced8c5b34454955da89174 (SHA256)\r\n340795d1f2c2bdab1f2382188a7b5c838e0a79d3f059d2db9eb274b0205f6981 (SHA256)\r\n7f0a314f15a6f20ca6dced545fbc9ef8c1634f9ff8eb736deab73e46ae131458 (SHA256)\r\nbe5f4bfa35fc1b350d38d8ddc8e88d2dd357b84f254318b1f3b07160c3900750 (SHA256)\r\n9b955d9d7f62d405da9cf05425c9b6dd3738ce09160c8a75d396a6de229d9dd7 (SHA256)\r\nfd6e7fc11a325c498d73cf683ecbe90ddbf0e1ae1d540b811012bd6980eed882 (SHA256)\r\n6bf9d311ed16e059f9538b4c24c836cf421cf5c0c1f756fdfdeb9e1792ada8ba (SHA256)\r\nC2 Domains:\r\nalgew[.]me\r\naloqd[.]pw\r\nbpee[.]pw\r\nbvyv[.]club\r\nbwuk[.]club\r\ncgqy[.]us\r\ncihr[.]site\r\nckwl[.]pw\r\ncnmah[.]pw\r\ncoec[.]club\r\ncuuo[.]us\r\ndaskd[.]me\r\ndbxa[.]pw\r\ndlex[.]pw\r\ndoof[.]pw\r\ndtxf[.]pw\r\ndvso[.]pw\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 14 of 17\n\ndyiud[.]com\r\neady[.]club\r\nenuv[.]club\r\neter[.]pw\r\nfbjz[.]pw\r\nfhyi[.]club\r\nfuth[.]pw\r\ngjcu[.]pw\r\ngjuc[.]pw\r\ngnoa[.]pw\r\ngrij[.]us\r\ngxhp[.]top\r\nhvzr[.]info\r\nidjb[.]us\r\nihrs[.]pw\r\njimw[.]club\r\njomp[.]site\r\njxhv[.]site\r\nkjke[.]pw\r\nkshv[.]site\r\nkwoe[.]us\r\nldzp[.]pw\r\nlhlv[.]club\r\nlnoy[.]site\r\nlvrm[.]pw\r\nlvxf[.]pw\r\nmewt[.]us\r\nmfka[.]pw\r\nmjet[.]pw\r\nmjut[.]pw\r\nmvze[.]pw\r\nmxfg[.]pw\r\nnroq[.]pw\r\nnwrr[.]pw\r\nnxpu[.]site\r\noaax[.]site\r\nodwf[.]pw\r\nodyr[.]us\r\nokiq[.]pw\r\noknz[.]club\r\nooep[.]pw\r\nooyh[.]us\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 15 of 17\n\notzd[.]pw\r\noxrp[.]info\r\noyaw[.]club\r\npafk[.]us\r\npalj[.]us\r\npbbk[.]us\r\nppdx[.]pw\r\npvze[.]club\r\nqefg[.]info\r\nqlpa[.]club\r\nqznm[.]pw\r\nreld[.]info\r\nrnkj[.]pw\r\nrzzc[.]pw\r\nsgvt[.]pw\r\nsoru[.]pw\r\nswio[.]pw\r\ntijm[.]pw\r\ntsrs[.]pw\r\nturp[.]pw\r\nueox[.]club\r\nufyb[.]club\r\nutca[.]site\r\nvdfe[.]site\r\nvjro[.]club\r\nvkpo[.]us\r\nvpua[.]pw\r\nvqba[.]info\r\nvwcq[.]us\r\nvxqt[.]us\r\nvxwy[.]pw\r\nwfsv[.]us\r\nwqiy[.]info\r\nwvzu[.]pw\r\nxhqd[.]pw\r\nyamd[.]pw\r\nyedq[.]pw\r\nyqox[.]pw\r\nysxy[.]pw\r\nzcnt[.]pw\r\nzdqp[.]pw\r\nzjav[.]us\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 16 of 17\n\nzjvz[.]pw\r\nzmyo[.]club\r\nzody[.]pw\r\nzugh[.]us\r\ncspg[.]pw\r\nSource: http://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nhttp://blog.talosintelligence.com/2017/03/dnsmessenger.html\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://blog.talosintelligence.com/2017/03/dnsmessenger.html"
	],
	"report_names": [
		"dnsmessenger.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775446638,
	"ts_updated_at": 1775791271,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e5a62dc2b8ba63589fb6da3ea94681f07a3b7679.pdf",
		"text": "https://archive.orkl.eu/e5a62dc2b8ba63589fb6da3ea94681f07a3b7679.txt",
		"img": "https://archive.orkl.eu/e5a62dc2b8ba63589fb6da3ea94681f07a3b7679.jpg"
	}
}