{
	"id": "b9e881c2-fea6-486a-966a-ff798152af95",
	"created_at": "2026-04-06T00:07:04.59701Z",
	"updated_at": "2026-04-10T03:22:06.408663Z",
	"deleted_at": null,
	"sha1_hash": "34e4f1dc826d372999d0efcf7258fd9e838de383",
	"title": "Malicious IIS extensions quietly open persistent backdoors into servers | Microsoft Security Blog",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 3105716,
	"plain_text": "Malicious IIS extensions quietly open persistent backdoors into\r\nservers | Microsoft Security Blog\r\nBy Microsoft Threat Intelligence\r\nPublished: 2022-07-26 · Archived: 2026-04-05 17:48:00 UTC\r\nAttackers are increasingly leveraging Internet Information Services (IIS) extensions as covert backdoors into servers,\r\nwhich hide deep in target environments and provide a durable persistence mechanism for attackers. While prior research\r\nhas been published on specific incidents and variants, little is generally known about how attackers leverage the IIS\r\nplatform as a backdoor.\r\nMalicious IIS extensions are less frequently encountered in attacks against servers, with attackers often only using script\r\nweb shells as the first stage payload. This leads to a relatively lower detection rate for malicious IIS extensions\r\ncompared to script web shells. IIS backdoors are also harder to detect since they mostly reside in the same directories as\r\nlegitimate modules used by target applications, and they follow the same code structure as clean modules. In most cases,\r\nthe actual backdoor logic is minimal and cannot be considered malicious without a broader understanding of how\r\nlegitimate IIS extensions work, which also makes it difficult to determine the source of infection.\r\nTypically, attackers first exploit a critical vulnerability in the hosted application for initial access before dropping a\r\nscript web shell as the first stage payload. At a later point in time, the attackers then install an IIS backdoor to provide\r\nhighly covert and persistent access to the server. Attackers can also install customized IIS modules to fit their purposes,\r\nas we observed in a campaign targeting Exchange servers between January and May 2022, as well as in our prior\r\nresearch on the custom IIS backdoors ScriptModule.dll and App_Web_logoimagehandler.ashx.b6031896.dll. Once\r\nregistered with the target application, the backdoor can monitor incoming and outgoing requests and perform additional\r\ntasks, such as running remote commands or dumping credentials in the background as the user authenticates to the web\r\napplication.\r\nAs we expect attackers to continue to increasingly leverage IIS backdoors, it’s vital that incident responders understand\r\nthe basics of how these attacks function to successfully identify and defend against them. Organizations can further\r\nimprove their defenses with Microsoft 365 Defender, whose protection capabilities are informed by research like this\r\nand our unique visibility into server attacks and compromise. With critical protection features like threat and\r\nvulnerability management and antivirus capabilities, Microsoft 365 Defender provides organizations with a\r\ncomprehensive solution that coordinates protection across domains, spanning email, identities, cloud, and endpoints.\r\nIn this blog post, we detail how IIS extensions work and provide insight into how they are being leveraged by attackers\r\nas backdoors. We also share some of our observations on the IIS threat landscape over the last year to help defenders\r\nidentify and protect against this threat and prepare the larger security community for any increased sophistication. More\r\nspecifically, the blog covers the following topics:\r\nUnderstanding IIS extensions\r\nAttack flow using a custom IIS backdoor\r\nCommand runs\r\nCredential access\r\nRemote access\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 1 of 13\n\nExfiltration\r\nTypes of IIS backdoors\r\nWeb shell-based variants\r\nOpen-source variants\r\nIIS handlers\r\nCredential stealers\r\nImproving defenses against server compromise\r\nUnderstanding IIS extensions\r\nIIS is a flexible, general purpose web server that has been a core part of the Windows platform for many years now. As\r\nan easy-to-manage, modular, and extensible platform for hosting websites, services, and applications, IIS serves critical\r\nbusiness logic for numerous organizations. The modular architecture of IIS allows users to extend and customize web\r\nservers according to their needs. These extensions can be in the form of native (C/C++) and managed (C#, VB.NET)\r\ncode structures, with the latter being our focus on this blog post. The extensions can further be categorized as modules\r\nand handlers.\r\nThe IIS pipeline is a series of extensible objects that are initiated by the ASP.NET runtime to process a request. IIS\r\nmodules and handlers are .NET components that serve as the main points of extensibility in the pipeline. Each request is\r\nprocessed by multiple IIS modules before being processed by a single IIS handler. Like a set of building blocks,\r\nmodules and handlers are added to provide the desired functionality for the target application. In addition, handlers can\r\nbe configured to respond to specific attributes in the request such a URL, file extension, and HTTP method. For\r\nexample, Aspnet_isapi.dll is a pre-configured IIS handler for common .aspx extensions.\r\nCreating custom managed IIS modules\r\nTo create a managed IIS module, the code must implement the IHttpModule interface. The IHttpModule interface has\r\ntwo methods with the following signatures: Init() and Dispose().\r\nFigure 1. IIS module skeleton\r\nInside Init(), the module can synchronize with any number of HTTP events available in the request pipeline, listed here\r\nin sequential order:\r\nBeginRequest\r\nAuthenticateRequest\r\nAuthorizeRequest\r\nResolveRequestCache\r\nAcquireRequestState\r\nPreRequestHandlerExecute\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 2 of 13\n\nPostRequestHandlerExecute\r\nReleaseRequestState\r\nUpdateRequestCache\r\nEndRequest\r\nPreSendRequestHeaders\r\nPreSendRequestContent\r\nThe newly created extension should then be mapped with the target application to complete the registration. Generally,\r\nthere are several methods that can be used to map managed modules for legitimate purposes. On the other hand, we\r\nobserved that attackers used the following techniques to register malicious IIS extensions during attacks:\r\nRegister with global assembly cache (GAC) PowerShell API: Every device with Common Language Runtime (CLR)\r\nhosts a device-wide cache called the global assembly cache (GAC). The GAC stores assemblies specifically designated\r\nto be shared by several applications on the device. GacInstall() is a PowerShell API to add modules into the global\r\ncache. Once installed, the module is available under the path %windir%\\Microsoft.NET\\assembly and is mapped to IIS\r\n(w3wp.exe) using appcmd.exe.\r\nFigure 2. Attacker command using the GAC PowerShell API\r\nRegister using appcmd.exe: Appcmd.exe is the single command line tool for managing IIS. All critical aspects, such as\r\nadding or removing modules and handlers, can be performed using the utility. In this case, the attackers drop the\r\nmalicious extension in the target application’s /bin folder and map it using the add module command.\r\nFigure 3. Attacker command using appcmd.exe\r\nRegister using gacutil.exe: Gacutil.exe is a Visual Studio shipped .NET GAC utility. The tool allows the user to view\r\nand manipulate the contents of the GAC, including installing new modules using the -I option.\r\nFigure 4. Attacker command using gacutil.exe\r\nRegister using web.config: After dropping the module in the application’s /bin folder, attackers can also edit the\r\nweb.config of the target application or the global config file, applicationHost.config, to register the module.\r\nFigure 5. Malicious web.config entry\r\nUpon successful registration, the module is visible inside the IIS manager application.\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 3 of 13\n\nFigure 6. Installed module visible in the list\r\nAttack flow using a custom IIS backdoor\r\nBetween January and May 2022, our IIS-related detections picked up an interesting campaign targeting Microsoft\r\nExchange servers. Web shells were dropped in the path %ExchangeInstallPath%\\FrontEnd\\HttpProxy\\owa\\auth\\ via\r\nProxyShell exploit.\r\nAfter a period of doing reconnaissance, dumping credentials, and establishing a remote access method, the attackers\r\ninstalled a custom IIS backdoor called FinanceSvcModel.dll in the folder C:\\inetpub\\wwwroot\\bin\\. The backdoor had\r\nbuilt-in capability to perform Exchange management operations, such as enumerating installed mailbox accounts and\r\nexporting mailboxes for exfiltration, as detailed below.  \r\nCommand runs\r\nPowerShDLL toolkit, an open-source project to run PowerShell without invoking powershell.exe, was used to run\r\nremote commands. The attacker avoided invoking common living-off-the-land binaries (LOLBins), such as cmd.exe or\r\npowershell.exe in the context of the Exchange application pool (MSExchangeOWAAppPool) to evade related detection\r\nlogic.\r\nFigure 7. Using PowerShDLL to run remote commands\r\nCredential access\r\nThe attackers enabled WDigest registry settings, which forced the system to use WDigest protocol for authentication,\r\nresulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attackers to\r\nsteal the actual password, not just the hash. Later, Mimikatz was run to dump local credentials and perform a DCSYNC\r\nattack.\r\nFigure 8. Mimikatz usage\r\nRemote access\r\nThe attackers used plink.exe, a command-line connection tool like SSH. The tool allowed the attackers to bypass\r\nnetwork restrictions and remotely access the server through tunneled RDP traffic.\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 4 of 13\n\nFigure 9. Bypassing network restrictions\r\nExfiltration\r\nThe attacker invoked the IIS backdoor by sending a crafted POST request with a cookie EX_TOKEN. The module\r\nextracts the cookie value and initiates a mailbox export request with the supplied filter.\r\nFigure 10. Attacker-generated POST request\r\nThe value decodes to: ep,06/21/2022,06/21/2022,C:\\Windows\\Web,Administrator, where ep is the command to initiate\r\nthe mailbox export request with filters determining the start and end dates followed by the export path. The final\r\ncommand has the following syntax:\r\nFigure 11. Attacker-generated mailbox export request\r\n Figure 12. Mailbox export code snippet\r\nThe table below details all the commands found in the backdoor:\r\nCommand Description\r\ntest\r\nAttempts to load Exchange Management Shell (EMS)- Add-PSSnapin\r\nMicrosoft.Exchange.Management.Powershell.SnapIn\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 5 of 13\n\nbox\r\nList all UserPrincipalNames-  foreach ($name in Get-Mailbox -ResultSize unlimited){\r\nWrite-Output $name.UserPrincipalName}\r\nep\r\nRun New-MailboxExportRequest cmdlet with supplied mailbox name, start and end\r\ndate, and export path as filters.\r\ngep Get the task ID associated with the export request\r\nruh Tamper with Exchange logs\r\nTypes of IIS backdoors\r\nReviewing the malicious managed (.NET) IIS extensions observed over the past year, we grouped these extensions\r\nbased on various factors such as similar capabilities and sources of origin, as further detailed in the below sections. \r\nWeb shell-based variants\r\nWeb shells like China Chopper have been widely used in numerous targeted attacks. As China Chopper’s usage\r\nincreased over the years, so did the detections. As a result, the attackers evolved and added IIS module-based versions\r\nof these web shells that maintain the same functionality. The module uses the same eval() technique that’s used in the\r\nscript version for running the code. While most antivirus solutions would detect the one-liner web shell, such as \u003c\r\n%@page language=js%\u003e\u003c%eval(request.item(\u003cpassword\u003e),”unsafe”);%\u003e, embedding the same code in an IIS\r\nmodule generates lower detection rates.\r\nIn the module version, the attacker-initiated POST request contains the code along with the arguments in parameters z1\r\nand z2, like the script-based version.\r\nFigure 13. China chopper IIS module – version 1\r\nFigure 14. Attacker generated POST data – version 1\r\nIn a different version, the module has the backdoor logic hardcoded inside the DLL and only waits for parameters z1\r\nand z2. The parameter kfaero has the command exposed as sequential alphabets from ‘A-Q’.\r\nFigure 15. China chopper IIS module – version 2\r\nLike the script version, the IIS module has similar capabilities, such as listing and creating directories, downloading and\r\nuploading files, running queries using SQL adaptors, and running commands. To run commands, the attacker-initiated\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 6 of 13\n\nPOST request contains the command “M” along with the arguments.\r\nFigure 16. An example of an attacker generated POST data – version 2\r\nAntsword is another popular web shell widely used in various targeted attacks. Custom IIS modules inspired from the\r\nweb shell’s code have been observed in the wild, which include similar architecture and capabilities. Interesting new\r\nfeatures of these malicious modules include fileless execution of C# code and remote access via TCP socket connection.\r\nFigure 17. Antsword IIS module code snippet\r\nBased on the request, the module can take one of the two code paths. In case of /server-status, a socket connection is\r\ninitiated from values in the custom header Lhposzrp.\r\nCommand Description\r\nFSoaij7_03Ip3QuzbIhvuilKIsoM9a48DTkvQKdwtKNA Socket connection\r\n8CDztbQb4fsQeU5AAuBs9OmRokoyFJ7F5Z Close connection\r\n31FKvk8VDcqZMA3iAq3944wjg Send data\r\nTU_LDzOsv Receive data\r\nFor any other URL, the module follows a China Chopper-style architecture of commands, ranging from “A” through\r\n“R”. The additional “R” command allows the attackers to run C# code reflectively.\r\nFigure 18. Command “R” to invoke code reflectively\r\nOpen-source variants\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 7 of 13\n\nGitHub projects on creating backdoors for IIS have been available for some time now. Though mostly shared to educate\r\nthe red team community, threat actors have also taken interest and lifted code from these projects. Using a public project\r\nthat has been actively leveraged by attackers as an example, the original code includes the following capabilities:\r\nCommand Implementation\r\ncmd Run command via cmd.exe /c\r\npowershell Run powershell via RunspaceFactory.CreateRunspace()\r\nshellcode Inject supplied shellcode into userinit.exe\r\nIn this case, the in-the-wild variants change the cookie names, keeping the rest of the code intact:\r\nFigure 19. Side to side comparison of code from an open-source project (left) and code used by attackers\r\n(right)\r\nOn supplying a whoami command to the backdoor, the generated cookie has the following format:\r\nCookie: BDUSS=P6zUsk/1xJyW4PPufWsx5w==\r\nThe backdoor responds with an AES encrypted blob wrapped in base64. The decoded output has the following format:\r\nFigure 20. Decoded response from the server\r\nIIS handlers\r\nAs mentioned earlier, IIS handlers have the same visibility as modules into the request pipeline. Handlers can be\r\nconfigured to respond to certain extensions or requests. To create a managed IIS handler, the code must implement\r\nthe IHttpHandler interface. The IHttpHandler interface has one method and one property with the following signatures:\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 8 of 13\n\nFigure 21. IIS handler skeleton\r\nHandlers can be registered by directly editing the web.config file or using the appcmd utility. The handler config takes a\r\nfew important fields like path, which specifies the URL or extensions the handler should respond to, and verb, which\r\nspecifies the HTTP request type. In the example below, the handler only responds to image requests ending with a .gif\r\nextension:\r\nFigure 22. Malicious web.config entry\r\nThe handler is visible in the IIS manager application once successfully installed:\r\nFigure 23. Installed handler visible in the list\r\nMost of the handlers analyzed were relatively simple, only including the capability to run commands:\r\nFigure 24. IIS handler running commands via cmd.exe\r\nInterestingly, the response Content-Type is set to image/gif or image/jpeg, which presents a default image when\r\nbrowsing the image URL with the output hidden in \u003cpre\u003e tags. A possible reason for this could be to bypass network\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 9 of 13\n\ninspection since image files are generally considered non-malicious and are filtered and identified based on extensions.\r\nCredential stealers\r\nThis subset of modules monitors sign-in patterns in outgoing requests and dumps extracted credentials in an encrypted\r\nformat. The stolen credentials allow the attackers to remain persistent in the environment, even if the primary backdoor\r\nis detected.  \r\nThe modules monitor for specific requests to determine a sign-in activity, such as /auth.owa default URL for OWA\r\napplication. On inspecting the request, the module dumps the credentials in a .dat file. The contents are encrypted using\r\nXOR with a hardcoded value and wrapped with base64 encoding. The below image depicts a decoded sample output:\r\nFigure 25. Sample decrypted entry\r\nFigure 26. Backdoor looking for OWA sign-in URL\r\nIn another variant, the module looks for common placeholder variables for passing credentials used in different ASP.Net\r\napplications. The dumped credentials are AES encrypted and wrapped with Base64 encoding, located in\r\n%programdata%\\log.txt.\r\nFigure 27. Backdoor looking for common credential placeholder variables\r\nFigure 28. Sample decrypted entry\r\nImproving defenses against server compromise\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 10 of 13\n\nAs we expect to observe more attacks using IIS backdoors, organizations must ensure to follow security practices to\r\nhelp defend their servers.\r\nApply the latest security updates\r\nIdentify and remediate vulnerabilities or misconfigurations impacting servers. Deploy the latest security updates,\r\nespecially for server components like Exchange as soon as they become available. Use Microsoft Defender\r\nVulnerability Management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.\r\nKeep antivirus and other protections enabled\r\nIt’s critical to protect servers with Windows antivirus software and other security solutions like firewall protection and\r\nMFA. Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to use\r\nartificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface\r\nreduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and Windows\r\nManagement Instrumentation (WMI). Turn on tamper protection features to prevent attackers from stopping security\r\nservices.\r\nIf you are worried that these security controls will affect performance or disrupt operations, engage with IT\r\nprofessionals to help determine the true impact of these settings. Security teams and IT professionals should collaborate\r\non applying mitigations and appropriate settings.\r\nReview sensitive roles and groups\r\nReview highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add\r\naccounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or\r\nremoval. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import\r\nexport and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.\r\nRestrict access\r\nPractice the principle of least-privilege and maintain good credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and enable MFA. Use\r\ntools like Microsoft Defender for Identity’s Local Administrator Password Solution (LAPS).\r\nPlace access control list restrictions on virtual directories in IIS. Also, remove the presence of on-premises Exchange\r\nservers when only used for recipient management in Exchange Hybrid environments.\r\nPrioritize alerts\r\nThe distinctive patterns of server compromise aid in detecting malicious behaviors and inform security operations teams\r\nto quickly respond to the initial stages of compromise. Pay attention to and immediately investigate alerts indicating\r\nsuspicious activities on servers. Catching attacks in the exploratory phase, the period in which attackers spend several\r\ndays exploring the environment after gaining access, is key. Prioritize alerts related to processes such\r\nas net.exe, cmd.exe originating from w3wp.exe in general.\r\nInspect config file and bin folder\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 11 of 13\n\nRegularly inspect web.config of your target application and ApplicationHost.config to identify any suspicious additions,\r\nsuch as a handler for image files—which is suspicious itself, if not outright malicious. Also, regularly scan installed\r\npaths like the application’s bin directory and default GAC location. Regularly inspecting the list of installed modules\r\nusing the appcmd.exe or gacutil.exe utilities is also advisable.\r\nHardik Suri\r\nMicrosoft 365 Defender Research Team\r\nAppendix\r\nMicrosoft Defender Antivirus detects these threats and related behaviors as the following malware:\r\nBackdoor:MSIL/SuspIISModule.G!gen\r\nBackdoor:MSIL/SuspIISModule.H!gen\r\nBackdoor:MSIL/SuspIISModule.K!gen\r\nBackdoor:MSIL/OWAStealer.B\r\nBackdoor:MSIL/OWAStealer.C\r\nBehavior:Win32/SuspGacInstall.B\r\nEndpoint detection and response (EDR)\r\nSuspicious IIS AppCmd Usage\r\nHunting queries\r\nTo locate malicious activity related to suspicious IIS module registration, run the following queries:\r\nSuspicious IIS module registration\r\nDeviceProcessEvents\r\n| where ProcessCommandLine has “appcmd.exe add module”\r\n| where InitiatingProcessParentFileName == “w3wp.exe”\r\nDeviceProcessEvents\r\n| where InitiatingProcessFileName == “powershell.exe”\r\n|where ProcessCommandLine has ” system.enterpriseservices.internal.publish”\r\n| where InitiatingProcessParentFileName == “w3wp.exe”\r\nDeviceProcessEvents\r\n|where ProcessCommandLine has ” \\\\gacutil.exe /I”\r\n| where InitiatingProcessParentFileName == “w3wp.exe”\r\nIndicators of compromise (IOCs)\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 12 of 13\n\nFile name SHA-256\r\nHttpCompress.dll  4446f5fce13dd376ebcad8a78f057c0662880fdff7fe2b51706cb5a2253aa569\r\nHttpSessionModule.dll  1d5681ff4e2bc0134981e1c62ce70506eb0b6619c27ae384552fe3bdc904205c\r\nRewriterHttpModule.dll c5c39dd5c3c3253fffdd8fee796be3a9361f4bfa1e0341f021fba3dafcab9739\r\nMicrosoft.Exchange.HttpProxy.\r\nHttpUtilities.dll\r\nd820059577dde23e99d11056265e0abf626db9937fc56afde9b75223bf309eb0\r\nHttpManageMoudle.dll 95721eedcf165cd74607f8a339d395b1234ff930408a46c37fa7822ddddceb80\r\nIIS_backdoor.dll e352ebd81a0d50da9b7148cf14897d66fd894e88eda53e897baa77b3cc21bd8a\r\nFinanceSvcModel.dll 5da41d312f1b4068afabb87e40ad6de211fa59513deb4b94148c0abde5ee3bd5\r\nApp_Web_system_web.ashx.dll 290f8c0ce754078e27be3ed2ee6eff95c4e10b71690e25bbcf452481a4e09b9d\r\nApp_Web_error.ashx.dll 2996064437621bfecd159a3f71166e8c6468225e1c0189238068118deeabaa3d\r\nSource: https://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nhttps://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.microsoft.com/security/blog/2022/07/26/malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers/"
	],
	"report_names": [
		"malicious-iis-extensions-quietly-open-persistent-backdoors-into-servers"
	],
	"threat_actors": [],
	"ts_created_at": 1775434024,
	"ts_updated_at": 1775791326,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/34e4f1dc826d372999d0efcf7258fd9e838de383.pdf",
		"text": "https://archive.orkl.eu/34e4f1dc826d372999d0efcf7258fd9e838de383.txt",
		"img": "https://archive.orkl.eu/34e4f1dc826d372999d0efcf7258fd9e838de383.jpg"
	}
}