{
	"id": "3ee3a7c1-7ef8-40e8-961f-ccd831f8f4b8",
	"created_at": "2026-04-06T00:18:51.606927Z",
	"updated_at": "2026-04-10T03:21:25.981262Z",
	"deleted_at": null,
	"sha1_hash": "c541610a0a2f23c4527d321f151c9e94c8b53902",
	"title": "TwoFace Webshell: Persistent Access Point for Lateral Movement",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 287548,
	"plain_text": "TwoFace Webshell: Persistent Access Point for Lateral Movement\r\nBy Robert Falcone, Bryan Lee\r\nPublished: 2017-07-31 · Archived: 2026-04-02 12:02:52 UTC\r\nWhile investigating a recent security incident, Unit 42 found a webshell that we believe was used by the threat actor to\r\nremotely access the network of a targeted Middle Eastern organization. The construction of the webshell was interesting by\r\nitself, as it was actually two separate webshells: an initial webshell that was responsible for saving and loading the second\r\nfully functional webshell. It is this second webshell that enabled the threat actor to run a variety of commands on the\r\ncompromised server. Due to these two layers, we use the name TwoFace to track this webshell.\r\nDuring our analysis, we extracted the commands executed by the TwoFace webshell from the server logs on the\r\ncompromised server. Our analysis shows that the commands issued by the threat actor date back to June 2016; this suggests\r\nthat the actor had access to this shell for almost an entire year. The commands issued show the actor was interested in\r\ngathering credentials from the compromised server using the Mimikatz tool. We also saw the attacker using the TwoFace\r\nwebshell to move laterally through the network by copying itself and other webshells to other servers.\r\nActor Activities using TwoFace\r\nThe web server logs on the system we examined that was compromised with the TwoFace shell gave us a glimpse into the\r\ncommands the actor executed through their malware. These commands also enabled us to create a profile of the actor,\r\nspecifically their intentions and the tools and techniques used to carry out their operation.\r\nOur analysis determined that five different IP addresses from four countries issued commands on the TwoFace shell, as seen\r\nin Table 1. As it is possible these originating IP address may themselves have been targeted and compromised, we have\r\nredacted the full IP addresses to hide the identities. The first command in the logs was issued on June 18, 2016, which was a\r\nsimple “whoami” command to get the username on the server. This single command was the only one by this specific IP\r\naddress which appears to be in Iran, and suggests that the actor may have initially compromised the server around this time\r\nand performed a quick check to see if the shell was loaded successfully.\r\nIP address Country Number of Commands Date of Activity Days Since Initial Command\r\n46.38.x.x Iran 1 2016-06-18 0\r\n178.32.x.x France 6 2016-09-28 103\r\n137.74.x.x France 16 2017-03-03 259\r\n192.155.x.x USA 61 2017-04-24 311\r\n46.4.x.x Germany 10 2017-05-03 320\r\nTable 1 IP Addresses seen issuing TwoFace Commands\r\nThree months after this single, initial command the next set of commands were sent. This time on September 28, 2016 a\r\nseries of twelve commands were sent from an IP address apparently in France. These commands provide additional insight\r\ninto the actor’s intentions. It is not certain why a time gap exists in issuing commands to the TwoFace webshell, although it\r\nis highly plausible this may simply be a visibility gap or even anti-detection measure taken by the actor. Rather than\r\nspeculating on this gap and subsequent time gaps between interactions, we will focus on the commands actor issued that\r\nprovide insight into this actor’s tactics, techniques, and procedures (TTPs).\r\nThe first command issued from this second IP address attempts to run a variant of the Mimikatz post-exploitation tool\r\n(m64.exe), specifically the Sekurlsa module that gathers the passwords of accounts currently logged into the system and\r\nsaves the results locally to a text file. The actor then issues a command that uses the “type” command to read the contents of\r\nthe text file containing the passwords, followed by a command that uses “del” to delete the text file.\r\nc:\\windows\\temp\\m64.exe privilege::debug sekurlsa::logonpasswords exit \u003e c:\\windows\\temp\\01.txt\r\nJust over five months later on March 3, 2017, a third IP address, a different one apparently in France, issued a series of 16\r\ncommands to the TwoFace webshell. The first command of interest is as follows:\r\nnet group \"Exchange Trusted Subsystem\" /domain\r\nAccording to MSDN, the “Exchange Trusted Subsystem” group is defined as follows:\r\nhttps://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nPage 1 of 7\n\nThe “Exchange Trusted Subsystem” is a highly privileged universal security group (USG) that has read/write access to\r\nevery Exchange-related object in the Exchange organization. It’s also a member of the Administrators local security group\r\nand the Exchange Windows Permissions USG, which enables Exchange to create and manage Active Directory objects.\r\nUsing hostnames obtained from the previous command, the actor issues several commands to determine if they have access\r\nto Microsoft Exchange related folders. The actor then issued several commands that attempt to copy a different webshell\r\nonto these additional systems, which resembles the following:\r\ncopy c:\\windows\\temp\\Exchange.aspx \"\\\\[hostname]\\d$\\Program Files\\Microsoft\\Exchange\r\nServer\\V14\\ClientAccess\\exchweb\\ews\\\"\r\nThis clearly shows the threat actor attempting to use the TwoFace webshell to pivot to other servers on the network. The\r\n“Exchange.aspx” file copied over to the other systems appears to be a different webshell from TwoFace. We analyzed this\r\nadditional webshell and have named it IntrudingDivisor, which we will describe in detail later in this blog.\r\nOn April 24, 2017, a fourth IP address, this one apparently in the United States, issued 61 commands to the TwoFace\r\nwebshell. Like the previous set of commands issued in March 2017 from France, this IP address issued the command to\r\nobtain objects in the Exchange Trusted Subsystem group, and it appears the actor copied over yet another webshell named\r\n“global.aspx” and set the file’s attributes to be hidden using the following command:\r\nattrib h \"\\\\[hostname]\\d$\\Program Files\\Microsoft\\Exchange Server\\V14\\ClientAccess\\exchweb\\ews\\global.aspx\"\r\nThe actor then issued commands that suggests the use of the Mimikatz tool, but this time Mimikatz was named\r\n“mom64.exe” instead of “m64.exe”. The following two commands show the actor killing the process and using the “type”\r\ncommand to read the contents of a text file “01.txt,” which was also used in the password gathering activity observed on the\r\nday of the initial compromise on Jun 2016, ten months earlier:\r\ntaskkill /f /im mom64.exe\r\ntype c:\\windows\\temp\\01.txt\r\nNine days later on May 3, 2017 the next commands came from a fifth IP address apparently in Germany. This time the threat\r\nactors issued 10 commands to the TwoFace webshell: fewer than nine days before but still more than during the other\r\nsessions.\r\nThe actor first issues a command to ping the IP address “4.2.2.4”, which is the legitimate DNS resolver operated by Level 3.\r\nThe actor then checks the “Domain Admins” group to determine the accounts with domain administrator privileges using the\r\nfollowing command:\r\nnet group \"Domain admins\" /domain\r\nAfter this command, the actor runs a variant of the Mimikatz tool to gather locally logged in passwords, this time using a\r\nfilename of “MicrosoftUpdate.exe” for the executable and “mic.txt” to store the results, as seen in the following command:\r\nc:\\windows\\temp\\MicrosoftUpdate.exe p::d s::l q \u003e c:\\windows\\temp\\mic.txt\r\nThese commands show the threat actors rely heavily on the TwoFace webshell to interact with compromised servers, but it\r\nalso appears that other webshells are used in addition to TwoFace, such as IntrudingDivisor. The commands also show the\r\nthreat actor’s reliance on the Mimikatz tool to steal passwords from systems, which they will then use to attempt to move\r\nlaterally amongst other servers by copying over webshells. Lastly, the timestamps of the commands suggest that the threat\r\nactor had maintained persistent access that they used intermittently to the compromised network using the TwoFace shell\r\nsince at least June 2016.\r\nTwoFace Loader Shell\r\nBoth components of the TwoFace shell, which we will refer to as the loader and payload components were written in C# and\r\nmeant to run on a webserver that supports ASP.NET. The author of the initial loader webshell included legitimate and\r\nexpected content that will be displayed if a visitor accesses the shell in a browser. The inclusion of expected content suggests\r\nthat the actors wished to use the TwoFace webshell for extended periods while remaining hidden.\r\nThe code in the loader webshell includes obfuscated variable names and the embedded payload is encoded and encrypted.\r\nTo interact with the loader webshell, the threat actor uses HTTP POST requests to the compromised server. As its name\r\nsuggests, the loader component is mainly responsible for saving and loading the payload component on the same server,\r\nallowing the actor to interact with the payload component that has far more functionality than the loader. However, the\r\nloader is also capable of the following functionality:\r\nSave the TwoFace payload to a specified file on the server\r\nhttps://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nPage 2 of 7\n\nDelete the TwoFace payload saved on the server\r\nWrite data to a specified file on the server\r\nDelete the entire folder on the server used to store the TwoFace payload\r\nThe TwoFace loader parses the HTTP POST requests issued by the actor and references data at specific locations, more\r\nspecifically at certain indexes within the posted data (C# “Request.Forms”) that the shell will use to determine the\r\nfunctionality the actor wishes to execute. While we did not have logs of HTTP requests for the loader shell, we were able to\r\ndetermine some of the indexes that the webshell will specifically access within the data. Table 2 shows the known indexes\r\nwithin the HTTP POST data that TwoFace references.\r\nRequest.Forms\r\nIndex\r\nDescription\r\n0\r\nIf set to a specific value (for example, \"931201\"), it creates a set of \"pre\" html tags with a string\r\nof numbers for reasons unknown.\r\n5 Data to write to a file on the server\r\n8 String name for the TwoFace webshell filename\r\n9\r\nContains base64 data provided by the actor to specify the command to run, as well as the\r\ndecryption key in the event the actor wishes to load the webshell\r\nTable 2 Indexes within Request.Forms that the TwoFace loader relies on\r\nAs you can see in the descriptions in Table 2, none of these locations contain the command that the actor wishes to execute.\r\nInstead, the actor must provide data in index 9 that was constructed to not only contain the command the actor wants to\r\nexecute, but also contains the key to decrypt the TwoFace payload component that is embedded within the loader. The data\r\nin index 9 will contain data at specific offsets, seen in Table 3 that the loader component will use to determine the command\r\nand the location of command specific data within the posted data (C# “Request.Forms”).\r\nOffset Value Description\r\n0 Varied The entirety of the data is used as a key to decrypt the TwoFace payload component\r\n25 8\r\nSpecifies the argument in the HTTP POST request that contains the string of the filename for the\r\nTwoFace webshell file\r\n26 1000 Minimum length required to write data to a specified file\r\n44 31 Contains the number of arguments needed to perform a file deletion operation?\r\n45 5 Specifies the argument within the POST request that contains the data to write to a file on the server\r\n57 36\r\nContains the number of arguments within the POST request to run a command to write data to a file\r\non the server\r\n61 13\r\nContains the number of arguments within the POST request to run a command to install the\r\nTwoFace payload webshell\r\n63 14 Contains the number of arguments needed to perform a folder deletion operation?\r\nTable 3 Offets of actor provided data used by the TwoFace loader\r\nSaving the TwoFace Payload\r\nThe main purpose of the loader shell is to install a secondary webshell on demand. The secondary webshell, which we call\r\nthe payload, is embedded within the loader in encrypted form and contains additional functionality that we will discuss in\r\nfurther detail. When the threat actor wants to interact with the remote server, they provide data that the loader will use to\r\nmodify a decryption key embedded within the loader that will be in turn used to decrypt the embedded TwoFace payload.\r\nThe decryption algorithm (below) is very simple, as it relies on basic arithmetic operations, specifically addition and\r\nsubtraction to decrypt the embedded payload.\r\nfor(int i = 0; i \u0026lt; key.Length; i++)\r\n    key[i] += actorProvidedData[i % actorProvidedData.Length];\r\nhttps://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nPage 3 of 7\n\nfor(int j=0;j\u0026lt;ciphertext.Length;j++)\r\n    ciphertext[j] -= key[j % key.Length];\r\nThe pseudocode above provides the logic used by the TwoFace loader to decrypt the ciphertext of the payload, which is\r\n1. Iterate through the key, modifying each byte by adding a value from the actor’s provided data\r\n2. Iterate through TwoFace payload ciphertext and subtracting each byte using a value from the modified key\r\nWe were able to determine the data that the threat actor would have to provide to successfully decrypt the embedded\r\nTwoFace payload, which is as follows:\r\n\\x15@^\\xbbs\\xfa\\xae\\x876\\x03`\\xffs\\x89\\xb9\r\n\\x9a\\xcb\\x02\\xec\\x8e\\xc3\\x92\\x7f\\xd6b\\xa8\\x1ag\\xb8\\xff\\x82\\x08\\xd0ALB\\xd8\\x0c)\\x91\\x82\\xc4\\x85\\xb2\\xa7\\xe6\\xea\\x8e\\x92\\xf9u\\x96\\xc1\\xef\\x\r\nAs you can surmise from the above characters, this does not appear to be a human generated string. We believe this is a\r\nmachine generated string used for this input data, which gives a bit of insight into the actors behind this webshell, as they\r\nwould have to use a tool to interact with to automate the use of these webshells, or at a minimum they would need to keep\r\ntrack of these machine generated user input strings to be able to interact with their webshells manually.\r\nTwoFace Payload Shell\r\nThe TwoFace payload shell requires a password that is sent within HTTP POST data or within the HTTP Cookie,\r\nspecifically with a field with a name “pwd”. The “pwd” field is used for authentication as a password, which the payload\r\nwill generate the SHA1 hash and compare it with a hash that is hardcoded within the payload. We extracted the SHA1\r\nhashes used for authentication from the known TwoFace shells, as seen in Table 4 and were able to find the associated\r\npassword string for three of them. One of the passwords, “RamdanAlKarim12” contains a phrase that means “Ramadan the\r\ngenerous” in Arabic (الكريم رمضان(. Another known password is “FreeMe!”, while the last known password contains what\r\nmay be an acronym of a middle eastern energy organization followed by “pass”. It is possible that the actor chose this\r\nacronym based on the targeted organization, but we cannot confirm this.\r\nSample SHA256 Embedded SHA1 Password\r\n8f0419493d… a2c9afd6adac242827adb00d76c20c491b2d2247\r\n0a77e28e6d… 6a0e681586988388d4a0690b6fb686715d92d069\r\n54c8bfa0be… 5e1c37bf3bd8a7567d46db63ed9b0aeed53e57fe\r\n818ac924fd… 37ada887553cf48715cc19131b8e661ac43718e9\r\nfd47825d75… 9789b5c0c13fb58c423bce5577873d413d9494be\r\n79c9a2a2b5… c56bc0d331a825fdea01c5437877d5e9e1cda2c4\r\ne33096ab3… 9f4e10484f4ceac34878d4f621a1ad8e580fd02a\r\nc116f078a0… 57dd9721f9837ebd24dea55a90a2a9e3e6ad6f1e\r\nTable 4 Authentication hashes and matching password strings used for TwoFace webshells\r\nMuch like the authentication password, a threat actor can issue commands to the TwoFace payload using either data sent\r\nwithin the HTTP Cookie or HTTP POST data itself. If using an HTTP Cookie to issue commands, the payload will split the\r\ncookie data using the delimiter “#=#” and will treat the first value as the command and the second value the data to pass to\r\nthe command. We enumerated the command handler, which can be seen in Table 5 that accepts a variety of commands to\r\ninteract with the compromised server.\r\nCommand\r\nArg\r\nField\r\nDescription\r\nExecute application or\r\ncommand\r\npro Executable to run command line commands\r\ncmd\r\nRuns a supplied command using “cmd.exe” or another executable supplied\r\nby the user via the “pro” field within the HTTP POST data.\r\nUpload a file to the server\r\nupl\r\nField name within the HTTP POST files that contains the file contents to\r\nsave to the server\r\nhttps://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nPage 4 of 7\n\nsav Path to save file to\r\nvir Boolean to save a file to a virtual path rather than a physical path\r\nnen\r\nSpecified name of file to upload, otherwise the script uses the filename of\r\nthe uploaded file from the HTTP POST request\r\nUpload data to a file in the\r\n%TEMP% folder\r\nupb Base64 encoded data that is decoded and saved to a file\r\nupd Filename in the %TEMP% folder to save ‘upb’ data to\r\nDelete a file in %TEMP%\r\nfolder\r\ndel Filename in the %TEMP% folder to delete\r\nDownload a file from the\r\nserver\r\ndon Path to file to download from the server\r\nView or set MAC\r\ntimestamps of a file\r\nhid\r\n1 = View the ‘tfil’ MAC times\r\n2 = Set ‘tfil’ file MAC times to match the file specified in the ‘ttar’ field\r\n3 = Set ‘tfil’ file MAC times to times specified in the ‘ttim’ field\r\ntfil Filename to get or set MAC times\r\nttar\r\nFilename to get MAC times, most likely a legitimate filename used to make\r\nuploaded files look as if they are legitimate\r\nttim Specific timestamp to set file MAC times to\r\nTable 5 Commands available within the TwoFace payload webshell\r\nWhile the commands within Table 5 are available within TwoFace, the threat actor does not have to manually issue these\r\nrequests within HTTP POST data, as the actor can interact with the webshell using a web form within the browser. We set up\r\nan IIS server to test the TwoFace webshell, which displays the user-interface seen in Figure 1.\r\nFigure 1 TwoFace payload webshell before authentication\r\nAt first, the text box in the row labeled “Login” has a red background, which means the user has not successfully provided\r\nthe password required to issue commands to the webshell. After entering the correct password in the login box, the box\r\nchanges from a red to green background, as seen in Figure 2. The actor can now interact with the compromised server using\r\nthe webshell, which runs the commands described in Table 5. In most cases, the output or results of commands are displayed\r\nimmediately below the webshell. For instance, in Figure 2 we issued the “whoami” command that used the Windows\r\ncommand-prompt to display the name of the current user account below the webshell.\r\nhttps://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nPage 5 of 7\n\nFigure 2 Issuing a command on TwoFace webshell after successfully authenticating\r\nTwoFace++ Loader\r\nWe discovered another version of the TwoFace loader shell that was structurally similar to the TwoFace loader shell\r\ndiscussed in this blog, as this version of TwoFace also contains an embedded payload shell in encrypted form. To use the\r\nembedded payload shell, the actor must provide a password that the loader shell will not only use for authentication, but also\r\nas a key to decrypt the payload.\r\nThe actor will provide the password in the HTTP POST data, specifically as a base64 encoded string within a field labeled\r\n“p”. The TwoFace++ loader will decode this password and concatenate a static salt value and compute the SHA1 hash of\r\nthis string. The loader then base64 encodes the SHA1 hash and compares it with a hardcoded base64 encoded string of a\r\nSHA1 hash needed for successful authentication. We know of the SHA1 hashes\r\n19be2493b7cc2d43e8bf245b6faf2c747be6bae5 and 26749c6b5308bb668eb954f4120607c2a9d620be used for\r\nauthentication, however, we have been unable to determine the passwords that would result in these hashes.\r\nThe TwoFace++ loader will use the actor provided password as a decryption key to decrypt the embedded payload shell. The\r\nloader will use the first 24 bytes of the actor’s password as a key, which it will use the 3DES symmetric cipher to decrypt the\r\npayload shell. The embedded payload is 8624 bytes, which we believe is another webshell based on the previous version of\r\nthe TwoFace loader, however, we have been unable to decrypt the payload to confirm.\r\nIntrudingDivisor Webshell\r\nOur analysis of the commands issued to the TwoFace webshell resulted in the discovery of another webshell that we call\r\nIntrudingDivisor. Like TwoFace, the IntrudingDivisor webshell requires the threat actor to authenticate before issuing\r\ncommands. To authenticate, the actor must provide two pieces of information, first an integer that is divisible by 5473 and a\r\nstring whose MD5 hash is “9A26A0E7B88940DAA84FC4D5E6C61AD0”. Upon successful authentication, the webshell\r\nhas a command handler that uses integers within the request to determine the command to execute, specifically integers\r\ndivisible by the following:\r\nDivisor Command\r\n6571 Write provided data to a specified file\r\n9273 Execute a command or change the modified and access times of a file\r\n3471 Read a specified file\r\nTable 6 Commands available within the IntrudingDivisor webshell\r\nThe webshell logs the IP, user-agent, and timestamp of all requests to a file named \"KB45253-ENU.exe”, but we have seen\r\nanother IntrudingDivisor sample logging requests to “KB76862-ENU.exe” as well. We believe the threat actor will use the\r\nIntrudingDivisor in a similar manner to TwoFace, specifically to gain access to additional servers during lateral movement\r\nand to gather user credentials.\r\nhttps://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nPage 6 of 7\n\nConclusion\r\nThe TwoFace webshell has an effective two-layer approach that makes it difficult to detect. Coupled with the multiple layers\r\nand inclusion of legitimate website content that displays correctly in the browser, the threat actors are able to enjoy long\r\nperiods of persistent access to a network without detection as evidenced by their demonstrated ability to access and\r\nmanipulate a compromised system for nearly a year. Based on the commands issued to TwoFace, the threat actors used this\r\nwebshell to deliver variants of the Mimikatz tool to gather the passwords of logged on accounts. The actor also used\r\nTwoFace to move laterally by copying webshells to other remote systems on the network.\r\nTwoFace Loader SHA256\r\ned684062f43d34834c4a87fdb68f4536568caf16c34a0ea451e6f25cf1532d51\r\nf4da5cb72246434decb8cf676758da410f6ddc20196dfd484f513aa3b6bc4ac5\r\n9a361019f6fbd4a246b96545868dcb7908c611934c41166b9aa93519504ac813\r\nd0ffd613b1b285b15e2d6c038b0bd4951eb40eb802617cf6eb4f56cda4b023e3\r\nTwoFace++ Loader SHA256\r\nbca01f14fb3cb4cfbe7f240156feebc55abac73a6c96b9f75da2f9df580101ef\r\n8d178b9730e09e35c071526bfb91ce72f876797ebc4e81f0bc05e7bb8ad1734e\r\nTwoFace Payload SHA256\r\n8f0419493da5ba201429503e53c9ccb8f8170ab73141bdc6ae6b9771512ad84b\r\n0a77e28e6d0d7bd057167ca8a63da867397f1619a38d5c713027ebb22b784d4f\r\n54c8bfa0be1d1419bf0770d49e937b284b52df212df19551576f73653a7d061f\r\n818ac924fd8f7bc1b6062a8ef456226a47c4c59d2f9e38eda89fff463253942f\r\nfd47825d75e3da3e43dc84f425178d6e834a900d6b2fd850ee1083dbb1e5b113\r\n79c9a2a2b596f8270b32f30f3e03882b00b87102e65de00a325b64d30051da4e\r\ne33096ab328949af19c290809819034d196445b8ed0406206e7418ec96f66b68\r\nc116f078a0b9ea25c5fdb2e72914c3446c46f22d9f2b37c582600162ed711b69\r\nIntrudingDivisor Shell SHA256\r\ne342d6bf07de1257e82f4ea19e9f08c9e11a43d9ad576cd799782f6e968914b8\r\n49f43f2caaea89bd3bb137f4228e543783ef265abbdc84e3743d93a7d30b0a7e\r\nMimikatz SHA256\r\nf17272d146f4d46dda5dc2791836bfa783bdc09ca062f33447e4f3a26f26f4e0\r\nSource: https://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nhttps://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/"
	],
	"report_names": [
		"unit42-twoface-webshell-persistent-access-point-lateral-movement"
	],
	"threat_actors": [],
	"ts_created_at": 1775434731,
	"ts_updated_at": 1775791285,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c541610a0a2f23c4527d321f151c9e94c8b53902.pdf",
		"text": "https://archive.orkl.eu/c541610a0a2f23c4527d321f151c9e94c8b53902.txt",
		"img": "https://archive.orkl.eu/c541610a0a2f23c4527d321f151c9e94c8b53902.jpg"
	}
}