{
	"id": "20d890c5-32b9-43cb-8687-ded4e68df60a",
	"created_at": "2026-04-06T00:16:45.188173Z",
	"updated_at": "2026-04-10T03:35:41.622411Z",
	"deleted_at": null,
	"sha1_hash": "7c8822e79f18b854a3b9ed2148410cea198c3408",
	"title": "From Hacking Team to hacked team to...?",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 387455,
	"plain_text": "From Hacking Team to hacked team to...?\r\nArchived: 2026-04-05 20:13:10 UTC\r\nVB2018 paper: From Hacking Team to hacked team to...?\r\nFilip Kafka\r\nESET, Slovakia\r\nCopyright © 2018 Virus Bulletin\r\nAbstract\r\nHacking Team first came under the spotlight of the security industry following its damaging data breach in July 2015.\r\nThe leaked data revealed several zero-day exploits being used and sold to governments, and confirmed suspicions\r\nthat Hacking Team had been doing business with oppressive regimes. But what happened to Hacking Team after one\r\nof the most famous hacks of recent years?\r\nHacking Team's flagship product, the Remote Control System (RCS), was detected in the wild at the beginning of\r\n2018 in 14 different countries, including some of those that had previously criticized the company's practices. In this\r\npaper, we will present the evidence that convinced us that the new, post-hack Hacking Team samples can be traced\r\nback to a single group – not just any group, but Hacking Team's developers themselves.\r\nFurthermore, we will share previously undisclosed insights into Hacking Team's post-leak operations, including the\r\ntargeting of diplomats in Africa, uncover the digital certificates used to sign the malware, and share details of the\r\ndistribution vectors used to target the victims. We will compare the functionality of the post-leak samples with that of\r\nthe leaked source code. To help other security researchers, we'll provide tips on how to efficiently extract details from\r\nthese newer VMProtect-packed RCS samples. Finally, we will show how Hacking Team sets up companies and\r\npurchases certificates for them.\r\nIntroduction\r\nSince being founded in 2003, the Italian spyware vendor Hacking Team has gained notoriety for selling surveillance\r\ntools to governments and their agencies across the world. The capabilities of its flagship product, the Remote Control\r\nSystem (RCS), include extracting files from a targeted device, intercepting emails and instant messaging, as well as\r\nremotely activating a device's webcam and microphone. The company has been criticized for selling these\r\ncapabilities to authoritarian governments [1] – an allegation it has consistently denied.\r\nWhen Hacking Team itself suffered a damaging hack in July 2015 [2], the reported use of RCS by oppressive regimes\r\nwas confirmed [3].\r\nThe 400GB of leaked internal data included:\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 1 of 11\n\nthe spyware source code\r\nthe spyware for different platforms\r\nfive zero-day exploits: 1x Windows LPE, 3x Adobe Flash, 1x Adobe Reader\r\na UEFI rootkit\r\nevidence of selling an injection proxy for performing various MitM attacks\r\nthe once-secret list of customers\r\nthe pricelist\r\ninternal communications\r\nDue to the severity of the leak, Hacking Team was forced to ask its customers to suspend all use of RCS, and was left\r\nfacing an uncertain future.\r\nThe security community has been keeping a close eye on the company's efforts to get back on its feet. With both the\r\nsource code and a ready-to-use builder leaked, it came as no surprise when cybercriminals started reusing the\r\nspyware. This was the case in January 2016, when Callisto Group reused the source code in one of their campaigns\r\n[4]. Recent reports have revealed that in June 2016, Hacking Team received funding from a mysterious investor with\r\nties to Saudi Arabia [5].\r\nDiscovery of post-leak samples\r\nIn the early stages of our investigation, the Citizen Lab provided us with RCS samples used in 2016 and 2017, which\r\nled to the discovery of a version of the spyware currently being used in the wild and signed with a previously unseen\r\nvalid digital certificate.\r\nOur further research uncovered several more samples of Hacking Team's spyware created after the 2015 hack, all\r\nbeing slightly modified compared to variants released before the source code leak.\r\nThe samples were compiled between September 2015 and October 2017. We have deemed these compilation dates to\r\nbe authentic, based on ESET telemetry data indicating the appearance of the samples in the wild within a few days of\r\nthose dates.\r\nUnpacking the samples\r\nAll the samples are packed with VMProtect, a commercial anti-piracy protector, which was also the case with pre-leak samples. We notified VMProtect's developers and asked them to blacklist the licence used to pack spyware, but\r\nno action was taken.\r\nIn this section, we will explain how we unpacked the samples of modified Hacking Team spyware.\r\nExtracting details from the VMProtect-packed samples\r\nThere are two approaches – the first is intended to extract only some (valuable) details from the sample, such as the\r\nC\u0026C; the second approach is to fully unpack the sample, including rebuilding the IAT (Import Address Table). The\r\nfirst approach is obviously easier and quicker, but to be able to fully analyse the samples, the second approach is\r\nneeded.\r\nFirst approach\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 2 of 11\n\nFor the first approach, the sample is run and after some time, when the sample unpacks itself, the process is dumped.\r\nThen the C\u0026C or other information can be searched for in the dump. Indeed, this is not a sophisticated method, but it\r\nis important to mention this easy but still effective approach. For dumping you can use:\r\n1. Hacking Team's VMProtect dumper – a simple tool developed by Hacking Team's developers, which runs the\r\nVMProtect-packed sample and dumps the process memory a few times after the sample unpacks itself.\r\n2. Any of your favourite memory-dumping tools.\r\nSecond approach\r\nThe second approach represents typical unpacking, and results in a fully working unpacked PE file. We unpacked the\r\nsample dynamically (i.e. by executing it).\r\nThis approach includes the following steps:\r\n1. Run the sample and find the OEP (Original Entry Point).\r\n2. If imports (calls to API) are wrapped, figure out the real API function and rewrite the wrapped call.\r\n3. Dump and rebuild imports with typical tools.\r\nThe steps explained in detail:\r\n1. As VMProtect users can choose various protection settings, including detection of virtual machine or\r\ndebugger, the difficulty of this part depends on what protection settings are used. We will first explain\r\nhow to do the unpacking when the protection is not set to detect a debugger or a virtual machine, then\r\nwe will extend our approach to bypass those detections.\r\n1. Run the sample inside the debugger. After some time, pause it. Then search in the memory for:\r\n1. Typical MSVC entry point. Programs compiled with Microsoft Visual Studio have\r\nvery common code on startup, so looking for 'magic bytes' in the initialization of\r\nthe security cookie (Figure 1) is enough to identify the OEP. Once the OEP has\r\nbeen identified, place a hardware breakpoint on the address and run the packed\r\nsample once again until it pauses at the OEP.\r\n2. If it wasn't compiled with Microsoft Visual Studio, or it is still somehow\r\nmasquerading, it is necessary to search for the code belonging to the original\r\napplication.\r\n2. If the protection is set to detect a debugger, it is necessary to use dumping tools as explained\r\nbefore, because there are no plug-ins available to successfully hide a debugger from VMProtect.\r\n2. Once the OEP is found, there might still be a problem with API functions – usually, VMProtect puts a\r\n'wrapper' on them. This means that it won't call APIs directly, but instead it calls code in the .vmp\r\nsection which computes the address of the API, pushes it on the stack, and finally returns to it. This\r\nwrapper makes work more difficult for typical IAT rebuilders. In order to get rid of the wrapper, it is\r\nnecessary to solve the address of the API and then rewrite the wrapped call to the real address of the\r\nAPI. Solving the address of the API can be done either by emulation or by execution until it returns\r\nfrom the .vmp section to the section with imports (usually the address starts with 0x7f....).\r\n3. When the OEP is found and imports are in the original form without the wrapper, the process can be\r\ndumped and the IAT rebuilt using typical tools like OllyDump, Scylla or ImpRec.\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 3 of 11\n\nFigure\r\n1: Typical bytes on entry point in programs compiled with Microsoft Visual Studio.\r\nAnalysis of the post-leak samples\r\nDistribution and targets\r\nAs for the distribution vector of the post-leak samples we analysed, in at least two cases, we detected the spyware in\r\nan executable file disguised as a PDF document. The names of the files suggest the malware was spread via spear-phising emails sent to high-profile targets such as diplomats:\r\n'Requirement for Diplomatic Passport Service.pdf.t.exe'\r\n'Note Verbale No 00023AM-ADD2017 du 17 janvier 2017 .exe'\r\n'Petition 2017\r\nrasdt.......................................................................................................................................................................t.exe'\r\n'rawshi nawaxoy harim kurdstan.exe'\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 4 of 11\n\nOur systems have detected these new Hacking Team spyware samples in 14 countries. We choose not to name the\r\ncountries in order to prevent potentially incorrect attributions based on these detections, since the geo-location of the\r\ndetections doesn't necessarily reveal anything about the origin of the attack.\r\nArchitecture and functionality\r\nThe malware has two stages – Scout (first stage) and Soldier or Elite (second stage; regular and premium version).\r\nThe second stage, the actual payload, is deployed after a few initial checks carried out by Scout.\r\nIn the post-leak samples we analysed, Scout and Soldier had the following functionality:\r\nScout (version 28):\r\nInstalls itself, checks if other instances are already running\r\nPerforms AV-bypassing tricks\r\nCollects basic information about the computer\r\nChecks for possible upgrades of itself / Soldier / Elite\r\nSoldier (version 1025):\r\nCollected data is packed, encrypted and stored in the registry and later sent to the C\u0026C server\r\nProper memory management, error handling\r\nCapabilities: steal data from clipboard, steal data from social networks, steal passwords and other data from\r\nbrowsers, take screenshots, activate camera, determine geolocation based on Wi-Fi networks, record Skype\r\ncalls, record keystrokes, monitor mouse clicks, schedule uninstallation of itself\r\nExample of a configuration embedded in the file:\r\n{\"camera\":{\"enabled\":false,\"repeat\":0,\"iter\":0},\"position\":{\"enabled\":false,\"repeat\":0},\"screenshot\":\r\n{\"enabled\":true,\"repeat\":120},\"photo\":{\"enabled\":false},\"file\":{\"enabled\":false},\"addressbook\":{\"enable\r\n:false},\"chat\":{\"enabled\":false},\"clipboard\":{\"enabled\":false},\"device\":{\"enabled\":true},\"call\":{\"enabl\r\n:false},\"messages\":{\"enabled\":false},\"password\":{\"enabled\":false},\"keylog\":{\"enabled\":false},\"mouse\":\r\n{\"enabled\":false},\"url\":{\"enabled\":false},\"sync\":{\"host\":\"149.154.153.223\",\"repeat\":120},\"uninstall\":\r\n{\"date\":null,\"enabled\":false}}\r\nAttribution\r\nFurther analysis led us to conclude that all the analysed post-leak samples can be traced back to a single group, rather\r\nthan being isolated instances of diverse actors building their own versions from the leaked Hacking Team source\r\ncode.\r\nCertificates\r\nOne indicator supporting this is the sequence of digital certificates used to sign the samples – we found six different\r\ncertificates issued in succession. Four of the certificates were issued by Thawte to four different companies, and two\r\nare personal certificates issued to Valeriano Bedeschi (Hacking Team co-founder) and someone named Raffaele\r\nCarnacina.\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 5 of 11\n\nFigure 2: The sequence of digital certificates used to sign the post-leak samples. Samples signed by Valeriano\r\nBedeschi were most likely used for testing purposes, as the C\u0026C was set to an internal network (172.16.1.206).\r\nVersioning\r\nThe versioning observed in the analysed samples continues where Hacking Team left off before the breach, and\r\nfollows the same patterns. Hacking Team's habit of compiling Scout and Soldier consecutively, and often on the same\r\nday, can also be seen across the newer samples.\r\nFigure 3 shows the compilation dates, versioning and certificate authorities of Hacking Team Windows spyware\r\nsamples seen between 2014 and 2017. Post-leak samples with renewed versioning begin with the sample signed by\r\nValeriano Bedeschi. Reuse of the leaked source code by Callisto Group is marked in red.\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 6 of 11\n\nFigure 3: Hacking Team Windows spyware samples seen between 2014 and 2017.\r\nModifications in line with Hacking Team development habits\r\nFurthermore, our research has confirmed that the changes introduced in the post-leak updates were made in line with\r\nHacking Team's own coding style. The changes are often found in places that indicate a deep familiarity with the\r\ncode, and follow Hacking Team's previously established development patterns (visible in the leaked source code).\r\nOther than these specific changes, the majority of the code is without any modifications. It is highly improbable that\r\nsome other actor – that is, other than the original Hacking Team developer(s) – would make changes in exactly these\r\nplaces when creating new versions from the leaked Hacking Team source code.\r\n1. Difference in Scout Startup file size\r\nAs shown in Figure 4, one of the subtle differences between the pre-leak and post-leak samples is a difference in\r\nStartup file size. When Scout installs on the system, it copies itself into the Windows Startup folder and appends\r\nrandom data to the end of the binary. This trick was used as an evasive technique against one anti-virus product.\r\nBefore the leak, the copied file was padded to occupy 4MB. In the post-leak samples, this file copy operation is\r\npadded to 6MB.\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 7 of 11\n\nFigure 4: Startup file size copy changed from 4MB pre-leak to 6MB post-leak.\r\n2. Improved random number generation\r\nScout samples from before the leak used the GetTickCount and Rand functions to generate random numbers for\r\nincreasing their size by appending the numbers at the end of the binary. In the post-leak samples, the number\r\ngeneration has been improved by using the CryptGenRandom API function. Only if this function fails are the\r\nprevious functions used.\r\n3. Changes in MySleep function\r\nHacking Team developers used their own MySleep function – in the samples from before the leak, it was\r\nimplemented for bypassing sleep patches in many sandboxes. It consisted of the GetCurrentThread and\r\nWaitForSingleObject Windows API functions. In the post-leak samples, the MySleep function is still present, but now\r\ncomprises the CreateEvent, WaitForSingleObject and CloseHandle Windows API functions.\r\n4. Change in fake error message strings\r\nThe pre-leak samples contain fake error message strings to be used in case the spyware is run with a system process\r\nID (i.e. 0 or 4). A process executed by a regular user would never have these ID values, so this trick might be aimed\r\nat sandboxes or emulators.\r\nThe content of the fake error messages had been changed regularly before the leak; the history of these changes was\r\nrevealed in the leaked source code (Figure 5).\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 8 of 11\n\nFigure 5: Fake strings history in the Scout leaked source code. RCS 9.5 includes Scout versions 11 and 12.\r\nIn the post-leak samples, the strings have been changed again, this time to the message 'Aborting now'.\r\n5. Change in user agents\r\nCompared to pre-leak samples, some of the parameters of the user-agent string used for HTTP protocol when\r\ncommunicating with the C\u0026C server are different in the newer samples. (See Figures 6 to 10.)\r\nFigure 6: User-agent string history in the Scout leaked source code. RCS 9.4 includes Scout version unknown; RCS\r\n9.5 includes Scout versions 11 and 12.\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 9 of 11\n\nFigure 7: Altered user-agent string in Scout version 15.\r\nFigure\r\n8: Altered user-agent string in Scout version 17.\r\nFigure\r\n9: Altered user-agent string in Scout version 22.\r\nFigure\r\n10: Altered user-agent string in Scout version 28.\r\n6. Changes in strings used for C\u0026C sync\r\nThe URL path used for HTTP protocol when communicating with the C\u0026C server is another part of the code that was\r\nfrequently changed in the pre-leak samples. In the post-leak samples, these paths also vary from sample to sample.\r\nFigure 11: Strings used\r\nfrom C\u0026C sync in the Scout leaked source code. RCS 9.4 includes Scout version unknown.; RCS 9.5 includes Scout\r\nversions 11 and 12.\r\nFigure 12: Alter URL Sync string in Scout version 15.\r\nFigure 13: Alter URL Sync string in Scout version 17.\r\nFigure 14: Alter URL Sync string in Scout version 18.\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 10 of 11\n\nFigure 15: Alter URL Sync string in Scout version 28.\r\nConclusion\r\nNone of these indicators, by themselves, represents conclusive evidence of Hacking Team's renewed activity.\r\nHowever, viewing them as a whole lets us claim with high confidence that, with one obvious exception, the post-leak\r\nsamples we've analysed are indeed the work of the Hacking Team developers, and not the result of source code reuse\r\nby unrelated actors, such as in the case of Callisto Group in 2016.\r\nReferences\r\n[1] The Citizen Lab. Mapping Hacking Team's \"Untraceable\" Spyware. February 2014.\r\nhttps://citizenlab.ca/2014/02/mapping-hacking-teams-untraceable-spyware/.\r\n[2] Franceschi-Bicchierai, L. Spy Tech Company 'Hacking Team' Gets Hacked. Motherboard. July 2015.\r\nhttps://motherboard.vice.com/en_us/article/gvye3m/spy-tech-company-hacking-team-gets-hacked.\r\n[3] Hern, A. Hacking Team hacked: firm sold spying tools to repressive regimes, documents claim. The Guardian.\r\nJuly 2015. https://www.theguardian.com/technology/2015/jul/06/hacking-team-hacked-firm-sold-spying-tools-to-repressive-regimes-documents-claim.\r\n[4] F-Secure Labs. Callisto Group. April 2017. https://www.f-secure.com/documents/996508/1030745/callisto-group.\r\n[5] Franceschi-Bicchierai, L. Hacking Team Is Still Alive Thanks to a Mysterious Investor From Saudi Arabia.\r\nMotherboard. January 2018. https://motherboard.vice.com/en_us/article/8xvzyp/hacking-team-investor-saudi-arabia.\r\nSource: https://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nhttps://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.virusbulletin.com/virusbulletin/2019/01/vb2018-paper-hacking-team-hacked-team/"
	],
	"report_names": [
		"vb2018-paper-hacking-team-hacked-team"
	],
	"threat_actors": [
		{
			"id": "a3687241-9876-477b-aa13-a7c368ffda58",
			"created_at": "2022-10-25T16:07:24.496902Z",
			"updated_at": "2026-04-10T02:00:05.010744Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "ETDA:Hacking Team",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e90c06e4-e3e0-4f46-a3b5-17b84b31da62",
			"created_at": "2023-01-06T13:46:39.018236Z",
			"updated_at": "2026-04-10T02:00:03.183123Z",
			"deleted_at": null,
			"main_name": "Hacking Team",
			"aliases": [],
			"source_name": "MISPGALAXY:Hacking Team",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "5dae3c71-8be1-4591-a2fb-b851ea6f083d",
			"created_at": "2022-10-25T16:07:23.432642Z",
			"updated_at": "2026-04-10T02:00:04.600341Z",
			"deleted_at": null,
			"main_name": "Callisto Group",
			"aliases": [],
			"source_name": "ETDA:Callisto Group",
			"tools": [
				"RCS Galileo"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "79bd28a6-dc10-419b-bee7-25511ae9d3d4",
			"created_at": "2023-01-06T13:46:38.581534Z",
			"updated_at": "2026-04-10T02:00:03.029872Z",
			"deleted_at": null,
			"main_name": "Callisto",
			"aliases": [
				"BlueCharlie",
				"Star Blizzard",
				"TAG-53",
				"Blue Callisto",
				"TA446",
				"IRON FRONTIER",
				"UNC4057",
				"COLDRIVER",
				"SEABORGIUM",
				"GOSSAMER BEAR"
			],
			"source_name": "MISPGALAXY:Callisto",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "3aedca2f-6f6c-4470-af26-a46097d3eab5",
			"created_at": "2024-11-01T02:00:52.689773Z",
			"updated_at": "2026-04-10T02:00:05.396502Z",
			"deleted_at": null,
			"main_name": "Star Blizzard",
			"aliases": [
				"Star Blizzard",
				"SEABORGIUM",
				"Callisto Group",
				"TA446",
				"COLDRIVER"
			],
			"source_name": "MITRE:Star Blizzard",
			"tools": [
				"Spica"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "3a057a97-db21-4261-804b-4b071a03c124",
			"created_at": "2024-06-04T02:03:07.953282Z",
			"updated_at": "2026-04-10T02:00:03.813595Z",
			"deleted_at": null,
			"main_name": "IRON FRONTIER",
			"aliases": [
				"Blue Callisto ",
				"BlueCharlie ",
				"CALISTO ",
				"COLDRIVER ",
				"Callisto Group ",
				"GOSSAMER BEAR ",
				"SEABORGIUM ",
				"Star Blizzard ",
				"TA446 "
			],
			"source_name": "Secureworks:IRON FRONTIER",
			"tools": [
				"Evilginx2",
				"Galileo RCS",
				"SPICA"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "61940e18-8f90-4ecc-bc06-416c54bc60f9",
			"created_at": "2022-10-25T16:07:23.659529Z",
			"updated_at": "2026-04-10T02:00:04.703976Z",
			"deleted_at": null,
			"main_name": "Gamaredon Group",
			"aliases": [
				"Actinium",
				"Aqua Blizzard",
				"Armageddon",
				"Blue Otso",
				"BlueAlpha",
				"Callisto",
				"DEV-0157",
				"G0047",
				"Iron Tilden",
				"Operation STEADY#URSA",
				"Primitive Bear",
				"SectorC08",
				"Shuckworm",
				"Trident Ursa",
				"UAC-0010",
				"UNC530",
				"Winterflounder"
			],
			"source_name": "ETDA:Gamaredon Group",
			"tools": [
				"Aversome infector",
				"BoneSpy",
				"DessertDown",
				"DilongTrash",
				"DinoTrain",
				"EvilGnome",
				"FRAUDROP",
				"Gamaredon",
				"GammaDrop",
				"GammaLoad",
				"GammaSteel",
				"Gussdoor",
				"ObfuBerry",
				"ObfuMerry",
				"PlainGnome",
				"PowerPunch",
				"Pteranodon",
				"Pterodo",
				"QuietSieve",
				"Remcos",
				"RemcosRAT",
				"Remote Manipulator System",
				"Remvio",
				"Resetter",
				"RuRAT",
				"SUBTLE-PAWS",
				"Socmer",
				"UltraVNC"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434605,
	"ts_updated_at": 1775792141,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/7c8822e79f18b854a3b9ed2148410cea198c3408.pdf",
		"text": "https://archive.orkl.eu/7c8822e79f18b854a3b9ed2148410cea198c3408.txt",
		"img": "https://archive.orkl.eu/7c8822e79f18b854a3b9ed2148410cea198c3408.jpg"
	}
}