{ "id": "ca2af944-50d1-451f-b2f1-07b599d43b73", "created_at": "2026-04-06T00:16:07.393609Z", "updated_at": "2026-04-10T03:34:57.56841Z", "deleted_at": null, "sha1_hash": "7f9f2844cef443f1e327a4d7d59ba7f4fabf0e6d", "title": "Waterbear Returns, Uses API Hooking to Evade Security", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 95098, "plain_text": "Waterbear Returns, Uses API Hooking to Evade Security\r\nBy By: Vickie Su, Anita Hsieh, Dove Chiu Dec 11, 2019 Read time: 9 min (2533 words)\r\nPublished: 2019-12-11 · Archived: 2026-04-05 18:53:32 UTC\r\nWaterbear, which has been around for several years, is a campaign that uses modular malware capable of including\r\nadditional functions remotely. It is associated with the cyberespionage group BlackTech, which mainly targets\r\ntechnology companies and government agencies in East Asia (specifically Taiwan, and in some instances, Japan and\r\nHong Kong) and is responsible for some infamous campaigns such as PLEAD and Shrouded Crossbow. In previous\r\ncampaigns, we’ve seen Waterbear primarily being used for lateral movement, decrypting and triggering payloads with\r\nits loader component. In most cases, the payloads are backdoors that are able to receive and load additional modules.\r\nHowever, in one of its recent campaigns, we’ve discovered a piece of Waterbear payload with a brand-new purpose:\r\nhiding its network behaviors from a specific security product by API hooking techniques. In our analysis, we have\r\ndiscovered that the security vendor is APAC-based, which is consistent with BlackTech’s targeted countries.\r\nKnowing which specific APIs to hook might mean that the attackers are familiar with how certain security products\r\ngather information on their clients' endpoints and networks. And since the API hooking shellcode adopts a generic\r\napproach, a similar code snippet might be used to target other products in the future and make Waterbear harder to\r\ndetect.\r\nA closer look at Waterbear\r\nWaterbear employs a modular approach to its malware. It utilizes a DLL loader to decrypt and execute an RC4-\r\nencrypted payload. Typically, the payload is the first-stage backdoor which receives and loads other executables from\r\nexternal attackers. These first-stage backdoors can be divided into two types: First, to connect to a command-and-control (C\u0026C) server, and second, to listen in on a specific port. Sometimes, the hardcoded file paths of the encrypted\r\npayloads are not under Windows native directories (e.g., under security products or third-party libraries' directories),\r\nwhich may indicate that the attackers might have prior knowledge of their targets' environments. It is also possible that\r\nthe attackers use Waterbear as a secondary payload to help maintain presence after gaining some levels of access to the\r\ntargets’ systems. The evidence is that Waterbear frequently uses internal IPs as its own C\u0026C servers (for\r\ninstance, b9f3a3b9452a396c3ba0ce4a644dd2b7f494905e820e7b1c6dca2fdcce069361 uses an internal IP address\r\nof 10[.]0[.]0[.]211 as its C\u0026C server).\r\nThe typical Waterbear infection chain\r\nintel\r\nFigure 1. A typical Waterbear infection chain\r\nA Waterbear infection starts from a malicious DLL loader, as shown in Figure 1. We have seen two  techniques of DLL\r\nloader triggering. One is modifying a legitimate server application to import and load the malicious DLL loader, while\r\nthe second technique is performing phantom DLL hijacking and DLL side loading. Some Windows services try to load\r\nexternal DLLs with hardcoded DLL names or paths during boot-up. However, if the DLL is a legacy DLL (i.e., one that\r\nis no longer supported by Windows) or a third-party DLL (i.e., one that is not part of the original Windows system\r\nhttps://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nPage 1 of 7\n\nDLLs), attackers can give their malicious DLL a hardcoded DLL name and place it under one of the searched\r\ndirectories during the DLL loading process. After the malicious DLL is loaded, it will gain the same permission level as\r\nthe service that loads it.\r\nDuring our recent Waterbear investigation, we discovered that the DLL loader loaded two payloads. The payloads\r\nperformed functionalities we have never seen in other Waterbear campaigns. The first payload injects code into a\r\nspecific security product to hide the campaign’s backdoor. The second payload is a typical Waterbear first-stage\r\nbackdoor, which we will attempt to dissect first based on a specific case we observed during our analysis.\r\nWaterbear’s first-stage backdoor\r\nWe saw a Waterbear loader named \"ociw32.dll\" inside one of the folders in the %PATH% environmental variable.\r\nThis DLL name is hardcoded inside \"mtxoci.dll\" which is loaded by the MSDTC service during boot-up. “mtxoci.dll”\r\nfirst tries to query the registry key \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSDTC\\MTxOCI\" to\r\nsee if the value \"OracleOciLib\" exists. If so, it retrieves the data inside it and loads the corresponding library. If the\r\nvalue doesn't exist, “mtxoci.dll” tries to load \"ociw32.dll\" instead. During our investigation, we noticed that the value\r\n\"OracleOciLib\" was deleted from the victim's machine, as shown in Figure 2. Hence, the malicious loader\r\n\"ociw32.dll\" was loaded and successfully executed on the host. intel\r\nFigure 2. The deleted value \"OracleOciLib\" on the victim's host\r\nNote: The image on the left  shows how  the DLL on a normal machine normally looks. The image on the right\r\nshowcases how the DLL on a victim's machine appears. Because there is no \"OracleOciLib\" value, it loads the\r\nhardcoded DLL \"ociw32.dll\" instead, which triggers the malicious Waterbear DLL loader.\r\nAfter the Waterbear DLL loader is executed, it searches for a hardcoded path and tries to decrypt the corresponding\r\npayload, which is a piece of encrypted shellcode. The decryption algorithm is RC4, which takes the hardcoded path to\r\nform the decryption key. If the decrypted payload is valid, it picks a specific existing Windows Service —\r\nLanmanServer, which is run by svchost.exe — and injects the decrypted shellcode into the legitimate service. In most\r\ncases, the payload is a first-stage backdoor, and its main purpose is to retrieve second-stage payloads — either by\r\nconnecting to a C\u0026C server or opening a port to wait for external connections and load incoming executables.\r\nConfiguration of the first-stage backdoor\r\nWaterbear’s first-stage backdoor configuration contains the information required for the proper execution of and\r\ncommunication with external entities.\r\nOffset 0x00, Size 0x10: Encryption / decryption key for the functions\r\nOffset 0x10, Size 0x04: 0x0BB8 (reserved)\r\nOffset 0x14, Size 0x10: Version (e.g., 0.13, 0.14, 0.16, and so on)\r\nOffset 0x24, Size 0x10: Mutex or reserved bytes\r\nOffset 0x34, Size 0x78: C\u0026C server address which is XOR-encrypted by key 0xFF. If the backdoor is intended\r\nto listen in on a specific port, this section will be filled with 0x00.\r\nOffset 0xAC, Size 0x02: Port\r\nOffset 0xAE, Size 0x5A: Reserved bytes\r\nTable: The function address table of the payload. The block is initially filled with 0x00 and will be propagated\r\nduring runtime.\r\nhttps://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nPage 2 of 7\n\nTable: The sizes of functions\r\nTable: The API address table. The block is initially filled with 0x00 and will be filled with loaded API addresses\r\nduring runtime.\r\nTable: The API hashes for dynamic API loading\r\nA list of DLL names and the number of APIs to be loaded\r\nintel\r\nFigure 3. The first-stage backdoor’s configuration structure\r\nAnti-memory scanning of shellcode payload\r\nIn order to avoid in-memory scanning during runtime, the payload encrypts all of the function blocks before executing\r\nthe actual malicious routine. Afterwards, whenever it needs to use a function, it will decrypt the function, execute it,\r\nand encrypt the function back again, as can be seen in Figure 4. If a function will not be used on the rest of the\r\nexecution, it will be scrambled by another mess-up function, as illustrated in Figure 6. The mess-up function muddles\r\nup the bytes with random values and makes the input blocks unrecoverable. The purpose of this is to further avoid\r\nbeing detected by a certain cybersecurity solution.\r\nintel\r\nFigure 4. The decryption-execution-encryption flow in the shellcode execution routine\r\nintel\r\nFigure 5. The function for the function block encryption and decryption\r\nintel\r\nFigure 6. The payload’s mess-up function\r\nSame Waterbear, different story\r\nDuring our investigation, we found a peculiar incident that stands out from most of the Waterbear infections we’ve\r\npreviously seen. This time, the DLL loader loaded two payloads – the first payload performed functionalities we have\r\nnot seen before: It injected codes into a specific security product to do API hooking in order to hide the backdoor from\r\nthe product. Meanwhile, the second payload is a typical Waterbear first-stage backdoor.\r\nintel\r\nFigure 7. An unusual Waterbear infection chain\r\nBoth payloads were encrypted and stored on the victim’s disk and were injected into the same service, which was, in\r\nthis case, LanmanServer. We have observed that the loader tried to read the payloads from the files, decrypted them,\r\nand performed thread injections with the following conditions:\r\n1. If the first payload could not be found on the disk, the loader would be terminated without loading the second\r\none.\r\nhttps://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nPage 3 of 7\n\n2. If the first payload was successfully decrypted and injected into the service, the second piece would also be\r\nloaded and injected regardless of what happened to the first thread.\r\n3. In the first injected thread, if the necessary executable from the security product was not found, the thread\r\nwould be terminated without performing other malicious routines. Note that only the thread would be\r\nterminated, but the service would still be running.\r\nRegardless if the API hooking was performed or otherwise, the second backdoor would still be executed after having\r\nbeen successfully loaded.\r\nAPI hooking to evade detection\r\nIn order to hide the behaviors of the first-stage backdoor (which is the second payload), the first payload uses API\r\nhooking techniques to avoid being detected by a specific security product and to make an interference in the result of\r\nthe function execution. It hooks two different APIs, namely \"ZwOpenProcess\" and \"GetExtendedTcpTable\", to hide\r\nits specific processes. The payload only modifies the functions in the memory of the security product process, hence\r\nthe original system DLL files remain unchanged.\r\nThe payload is composed of a two-stage shellcode. The first-stage shellcode finds a specific security product's process\r\nwith a hardcoded name and injects the second-stage shellcode into  that process. The second-stage shellcode then\r\nperforms API hooking inside the targeted process.\r\nHiding process identifiers (PIDs)\r\nThe process identifiers or PIDs to be hidden are stored in the shared memory \"Global\\\u003ccomputer_name\u003e.\" If the\r\nshared memory doesn't exist, it takes the PID embedded by the first-stage shellcode. In this case, the intention of the\r\nmalicious code is to hide Waterbear’s  backdoor activities from the security product. Therefore, the first-stage shellcode\r\ntakes the PID of the Windows Service — which the first-stage shellcode and the succeeding backdoor both inject into\r\n— hides the target process, and embeds that PID into the second-stage shellcode. intel  \r\nFigure 8. Code that injects current PID into the second-stage shellcode\r\nHooking \"ZwOpenProcess\" in ntdll.dll\r\nThe purpose of hooking “ZwOpenProcess” is to protect the specific process from being accessed by the security\r\nproduct. Whenever “ZwOpenProcess” is called, the injected code will first check if the opened process hits any PIDs\r\nin the protected process ID list. If yes, it modifies the process ID, which should open on another Windows Service PID.\r\nFirst, it builds the hooked function and writes the function at the end of “ntdll.dll”. This function includes two parts, as\r\nshown in Figure 9:\r\n1. The PID checking procedure. It recursively checks if the PID to be opened by “ZwOpenProcess” is in the list\r\nof the protected process IDs. If yes, it replaces the PID to be opened with another Windows Service PID that has\r\nbeen written by the Waterbear loader in the beginning.\r\n2. After the PID checking procedure, it executes the original “ZwOpenProcess” and returns the result.\r\nintel\r\nFigure 9. The function hook of “ZwOpenProcess” to check and modify the output of the function\r\nhttps://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nPage 4 of 7\n\nSecondly, it writes \"push \u003cADDRESS\u003e ret\" at the beginning of the original “ZwOpenProcess” address. Hence,\r\nwhen “ZwOpenProcess” is called, the modified version of “ZwOpenProcess” will be executed. intel\r\nFigure 10. “ZwOpenProcess” after modification\r\nThe API hooking on “ZwOpenProcess” will only be triggered if \"%temp%\\KERNELBASE.dll\" exists on the host.\r\nIt is possible that this check is designed according to the nature of the security product it targets.\r\n\"GetExtendedTcpTable\" and \"GetRTTAndHopCount\" hooks in iphlpapi.dll\r\nThe second part of API hooking hooks on “GetExtendedTcpTable.” “GetExtendedTcpTable” is used for retrieving a\r\ntable that contains a list of TCP endpoints available to the application, and it is frequently used in some network-related\r\ncommands, such as netstat. The purpose of the hook is to remove TCP endpoint records of certain PIDs. In order to\r\nachieve that, it modifies two functions: “GetExtendedTcpTable” and “GetRTTAndHopCount.” The second\r\nfunction, “GetRTTAndHopCount,” acts as the place to put the injected hooking code.\r\n“GetExtendedTcpTable” only writes a jump to “GetRTTAndHopCount” in the beginning of the function. Only the\r\nfirst 5 bytes of the code of the API \"GetExtendedTcpTable\" are changed, as shown in Figure 11.\r\nintel\r\nFigure 11. Only 5 bytes changed in the “GetExtendedTcpTable”\r\nThe rest of the routine is all placed in “GetRTTAndHopCount.” In the first part of the code, it pushes\r\n[“GetRTTAndHopCount”+0x3E] as the return address and then executes the first four instructions of the original\r\n“GetExtendedTcpTable” function (which has already been replaced by the jump instruction in Figure 11). After that,\r\nit jumps to “GetExtendedTcpTable” to execute the function normally and to catch its return values. The code is\r\nshown in Figure 12. intel\r\nFigure 12. The first part of injected code in “GetRTTAndHopCount,” which executes “GetExtendedTcpTable” and\r\nreturns back to the next instruction\r\nAfter “GetExtendedTcpTable” is executed and the process returns back to the second part of the code, it iteratively\r\nchecks every record in the returned Tcp table. If any record contains the PID Waterbear wants to hide, it will remove\r\nthe corresponding record, modify the record number inside the table, and continue to check the succeeding records. In\r\nthe end, it returns the modified table. intel\r\nFig. 13. The injected code’s second part in “GetRTTAndHopCount” that checks and removes returned records of\r\ncertain PIDs\r\nRather than directly disabling these two functions, this method of using API hooking makes noticing malicious\r\nbehaviors more difficult, especially since both functions still work and return results normally. Although in this case,\r\nthe affected process is specified in the first-stage shellcode, the API hooking logic is quite generic that the same piece\r\nof shellcode can be used to hook other vendors' products.\r\nConclusion\r\nThis is the first time we’ve seen Waterbear attempting to hide its backdoor activities. By the hardcoded product name,\r\nwe infer that the attackers are knowledgeable of the victims' environment and which security product(s) they use. The\r\nhttps://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nPage 5 of 7\n\nattackers might also be familiar with how security products gather information on their clients’ endpoints and\r\nnetworks, so that they know which APIs to hook. Since the API hooking shellcode adopts a generic approach, the\r\nsimilar code snippet might be used to target other products in the future and make the activities of Waterbear harder to\r\ndetect.\r\nTactic Technique ID Description\r\nExecution\r\nExecution through Module Load\r\nT1129\r\n \r\nDynamically loads the DLLs through the\r\nshellcode\r\nExecution through API\r\nT1106\r\n \r\nDynamically loads the APIs through the\r\nshellcode\r\nPersistence   Hooking\r\nT1179\r\n \r\nHooks security product’s commonly used\r\nAPIs\r\nPrivilege\r\nEscalation  \r\nProcess Injection T1055\r\nInjects the decrypts payload into svchost.exe\r\nprocess\r\nHooking\r\nT1179\r\n \r\nHooks security products’ commonly used\r\nAPIs\r\nDefense\r\nEvasion\r\nBinary Padding T1009 Adds junk data to evade anti-virus scan\r\nDisabling Security Tools T1089\r\nTargets a specific security product’s process\r\nfor injection purposes\r\nDeobfuscate/Decode Files or\r\nInformation\r\nT1140\r\nUses TROJ_WATERBEAR to decrypt\r\nencrypted payload\r\nExecution Guardrails T1480\r\nTargets specific software in the victim’s\r\nenvironment\r\nDLL Side-Loading\r\nT1073\r\n \r\nUses modified legitimate DLL to load the\r\nmalicious DLL\r\nProcess Injection T1055\r\nInjects the decrypted payload into\r\nsvchost.exe process\r\nExfiltration\r\nExfiltration Over Command and\r\nControl Channel\r\nT1041\r\nPossibly sends collected data to attackers via\r\nC\u0026C channel\r\nIndicators of Compromise (IoCs)\r\nSHA256 Detection Name\r\n649675baef92381ffcdfa42e8959015e83c1ab1c7bbfd64635ce5f6f65efd651 BKDR_WATERBEAR.ZTGF\r\nhttps://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nPage 6 of 7\n\n3909e837f3a96736947e387a84bb57e57974db9b77fb1d8fa5d808a89f9a401b TROJ_WATERBEAR.ZTGD\r\nfcfdd079b5861c0192e559c80e8f393b16ba419186066a21aab0294327ea9e58 TROJ_WATERBEAR.ZTGJ\r\n3f26a971e393d7f6ce7bf4416abdbfa1def843a0cf74d8b7bb841ca90f5c9ed9 TROJ_WATERBEAR.ZTGH\r\nabb91dfd95d11a232375d6b5cdf94b0f7afb9683fb7af3e50bcecdb2bd6cb035 TROJ_WATERBEAR.ZTGH\r\nbda6812c3bbba3c885584d234be353b0a2d1b1cbd29161deab0ef8814ac1e8e1 TROJ_WATERBEAR.ZTGI\r\n53402b662679f0bfd08de3abb064930af40ff6c9ec95469ce8489f65796e36c3 TROJ_WATERBEAR.ZTGH\r\nf9f6bc637f59ef843bc939cb6be5000da5b9277b972904bf84586ea0a17a6000 TROJ_WATERBEAR.ZTGI\r\n3442c076c8824d5da065616063a6520ee1d9385d327779b5465292ac978dec26 BKDR_WATERBEAR.ZTGD\r\n7858171120792e5c98cfa75ccde7cba49e62a2aeb32ed62322aae0a80a50f1ea TROJ64_WATERBEAR.ZTGI\r\nacb2abc7fb44c2fdea0b65706d1e8b4c0bfb20e4bd4dcee5b95b346a60c6bd31 BKDR_WATERBEARENC.ZTGF\r\nb9f3a3b9452a396c3ba0ce4a644dd2b7f494905e820e7b1c6dca2fdcce069361 BKDR64_WATERBEAR.ZTGD\r\n7c0d2782a33debb65b488893705e71a001ea06c4eb4fe88571639ed71ac85cdd BKDR_WATERBEARENC.ZTGH\r\nc7c7b2270767aaa2d66018894a7425ba6192730b4fe2130d290cd46af5cc0b7b BKDR_WATERBEARENC.ZTGI\r\n7532fe7a16ba1db4d5e8d47de04b292d94882920cb672e89a48d07e77ddd0138 BKDR_WATERBEARENC.ZTGI\r\ndea5c564c9d961ccf2ed535139fbfca4f1727373504f2972ac92acfaf21da831 BKDR_WATERBEARENC.ZTGI\r\n05d0ab2fbeb7e0ba7547afb013d307d32588704daac9c12002a690e5c1cde3a4 BKDR64_WATERBEARENC.ZTGJ\r\n39668008deb49a9b9a033fd01e0ea7c5243ad958afd82f79c1665fb73c7cfadf BKDR_WATERBEARENC.ZTGD\r\nSource: https://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nhttps://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA" ], "references": [ "https://blog.trendmicro.com/trendlabs-security-intelligence/waterbear-is-back-uses-api-hooking-to-evade-security-product-detection/" ], "report_names": [ "waterbear-is-back-uses-api-hooking-to-evade-security-product-detection" ], "threat_actors": [ { "id": "efa7c047-b61c-4598-96d5-e00d01dec96b", "created_at": "2022-10-25T16:07:23.404442Z", "updated_at": "2026-04-10T02:00:04.584239Z", "deleted_at": null, "main_name": "BlackTech", "aliases": [ "BlackTech", "Canary Typhoon", "Circuit Panda", "Earth Hundun", "G0098", "Manga Taurus", "Operation PLEAD", "Operation Shrouded Crossbow", "Operation Waterbear", "Palmerworm", "Radio Panda", "Red Djinn", "T-APT-03", "TEMP.Overboard" ], "source_name": "ETDA:BlackTech", "tools": [ "BIFROST", "BUSYICE", "BendyBear", "Bluether", "CAPGELD", "DRIGO", "Deuterbear", "Flagpro", "GOODTIMES", "Gh0stTimes", "IconDown", "KIVARS", "LOLBAS", "LOLBins", "Linopid", "Living off the Land", "TSCookie", "Waterbear", "XBOW", "elf.bifrose" ], "source_id": "ETDA", "reports": null }, { "id": "2646f776-792a-4498-967b-ec0d3498fdf1", "created_at": "2022-10-25T15:50:23.475784Z", "updated_at": "2026-04-10T02:00:05.269591Z", "deleted_at": null, "main_name": "BlackTech", "aliases": [ "BlackTech", "Palmerworm" ], "source_name": "MITRE:BlackTech", "tools": [ "Kivars", "PsExec", "TSCookie", "Flagpro", "Waterbear" ], "source_id": "MITRE", "reports": null }, { "id": "75024aad-424b-449a-b286-352fe9226bcb", "created_at": "2023-01-06T13:46:38.962724Z", "updated_at": "2026-04-10T02:00:03.164536Z", "deleted_at": null, "main_name": "BlackTech", "aliases": [ "CIRCUIT PANDA", "Temp.Overboard", "Palmerworm", "G0098", "T-APT-03", "Manga Taurus", "Earth Hundun", "Mobwork", "HUAPI", "Red Djinn", "Canary Typhoon" ], "source_name": "MISPGALAXY:BlackTech", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "3b93ef3c-2baf-429e-9ccc-fb80d0046c3b", "created_at": "2025-08-07T02:03:24.569066Z", "updated_at": "2026-04-10T02:00:03.730864Z", "deleted_at": null, "main_name": "BRONZE CANAL", "aliases": [ "BlackTech", "CTG-6177 ", "Circuit Panda ", "Earth Hundun", "Palmerworm ", "Red Djinn", "Shrouded Crossbow " ], "source_name": "Secureworks:BRONZE CANAL", "tools": [ "Bifrose", "DRIGO", "Deuterbear", "Flagpro", "Gh0stTimes", "KIVARS", "PLEAD", "Spiderpig", "Waterbear", "XBOW" ], "source_id": "Secureworks", "reports": null }, { "id": "c93a7f58-3f75-487c-9bd6-e705b73fc07f", "created_at": "2023-01-06T13:46:38.330916Z", "updated_at": "2026-04-10T02:00:02.931171Z", "deleted_at": null, "main_name": "RADIO PANDA", "aliases": [ "Shrouded Crossbow" ], "source_name": "MISPGALAXY:RADIO PANDA", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434567, "ts_updated_at": 1775792097, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/7f9f2844cef443f1e327a4d7d59ba7f4fabf0e6d.pdf", "text": "https://archive.orkl.eu/7f9f2844cef443f1e327a4d7d59ba7f4fabf0e6d.txt", "img": "https://archive.orkl.eu/7f9f2844cef443f1e327a4d7d59ba7f4fabf0e6d.jpg" } }