{
	"id": "dcca2a21-923b-4456-a8f7-ce81e1da4e4e",
	"created_at": "2026-04-06T00:21:35.069553Z",
	"updated_at": "2026-04-10T13:12:43.050865Z",
	"deleted_at": null,
	"sha1_hash": "06adc50aef05fea02d1d41b52fe51c1cde44c542",
	"title": "Snip3 Crypter | ThreatLabz",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5686844,
	"plain_text": "Snip3 Crypter | ThreatLabz\r\nBy Niraj Shivtarkar, Avinash Kumar\r\nPublished: 2023-02-24 · Archived: 2026-04-02 12:15:22 UTC\r\nInfection Chain\r\nFig 3. The Attack Chain\r\nThe ongoing Snip3 campaign constitutes a complex and multifaceted attack, which uses a series of sophisticated\r\nevasion techniques and multiple obfuscated scripts. The latest version of the Snip3 crypter is utilized to implement\r\nnew tactics, techniques, and procedures (TTPs), leading to the successful execution of the final payload and\r\nsubsequent system infection.\r\nThe attack is initiated through a spear phishing email that has the subject line \"Download your tax statement\" or,\r\nin French, \"Télécharger votre relevé fiscal.\" The emails are designed to create a sense of urgency and importance,\r\nthereby enticing users to open the attached files without much consideration. This marks the start of the infection\r\nchain.\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 1 of 17\n\nFig.4 Spear phishing email with tax statement bait and corresponding attachments\r\nThe screenshot above shows that the email contains several attachments, including a corrupted PDF file named\r\n\"Info.pdf\" and a corrupted CSV file named \"ID102332541.csv.\" These decoy files are included alongside the\r\nmalicious script called \"Votre Releve Fiscal-6.vbs\" in order to deceive the user into running it.\r\nStage-1: VBScript\r\nWhen the Stage-1 VBScript is executed, it establishes a connection to a database by creating an ADODB\r\nconnection and record object. The details of the provider, including the data source, user ID, and password, are\r\ndecrypted using an encoding method that utilizes the Chr and CLng functions, as illustrated in the screenshot\r\nbelow.\r\nFig.5 Stage-1 VBScript decoding the provider details using Chr and CLng functions\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 2 of 17\n\nDecoding routine:\r\nChr(657040/CLng(“\u0026H13fae”)) -\u003e Chr(657040/81838) -\u003e Character “P”\r\nAfter decoding the provider details, the script proceeds to establish a connection to the SQL8001.site4now.net data\r\nsource using the decoded user ID and password. If the connection is established successfully, it executes the\r\nfollowing two database queries to retrieve the relevant data from the table:\r\nSELECT ID, NAME, AGE, PHONE From TBL_CUSTOMERS\r\nSELECT * From TBL_PRODUCTS\r\nThe results of these queries are then processed using \"SqlReader.Fields.Item[index_val]\" to extract the values\r\nfrom each column, and the values are concatenated together as shown in the screenshot below.\r\nFig.6 Execution and parsing of database queries\r\nThe output from parsing and indexing the queries is saved into two variables named \"CustomerInfo\" and\r\n\"ProductInfo.\" The variables are populated with the following values after the execution and query parsing:\r\nCustomerInfo = \"Wscript.Shell\"\r\nProductInfo = \"Powershell.exe -ExecutionPolicy RemoteSigned -Command\"\r\nThis technique allows the script to avoid detection from static-string-based signatures for the specific command\r\nlines, as the values are retrieved after execution in memory.\r\nFollowing this, the script proceeds to decode a Downloader PowerShell script by replacing the string\r\n\"12BBf02emp410+]@Mdk!!#1022==\" with a null value. The decoded script is then saved into a variable named\r\n\"Camtasia,\" as shown below.\r\nFig.7 Decoding Downloader PS script using Replace()\r\nBelow is the decoded Downloader PowerShell Script:\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 3 of 17\n\nFig.8 Downloader PowerShell script\r\nThe decoded PowerShell script is saved in the \"Camtasia\" variable and executed together with the parsed database\r\nquery response from the server. This creates a WScript.shell object, which then runs the concatenated command\r\n\"Powershell.exe -ExecutionPolicy RemoteSigned -Command 'Decoded PowerShell Script'.\"\r\nFig.9 Execution of Downloader Powershell script\r\nAfter executing the decoded downloader PowerShell script, the Stage-2 PowerShell script is downloaded from\r\nhttps[:]pastetext.net/raw/lcscgt0mss using $Client.DownloadData in byte format. The script is then converted\r\nto string format using UTF8.GetString() and written to the disk at C:\\Users\\Public\\lcscgt0mss.ps1. The\r\ndownloaded Stage-2 PowerShell script is then executed using Invoke-Expression, with the execution policy set\r\nas RemoteSigned. This allows the PowerShell interpreter to run unsigned scripts from the local computer.\r\n \r\nStage-2: PasteText Downloaded PowerShell Script (lcscgt0mss.ps1)\r\nThe Stage-2 PowerShell script initially runs the \"DroptoStartUp\" function, which is illustrated in the screenshot\r\nbelow.\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 4 of 17\n\nFig.10 Stage-2 PowerShell script DroptoStartUp function\r\nUpon running the \"DroptoStartUp\" function, a byte stream is converted via GetString() to a string and stored in\r\nthe variable $startup. This string is then written to the Startup Folder using the WriteAllText() function and is\r\nnamed as \"GoogleChromeUpdateHandlerx64.vbs\". By doing this, the script is able to maintain persistence as\r\nfiles in the Startup Folder are executed by the system whenever the user logs on or starts Windows. The %FILE%\r\nargument is the $PSCommandPath environment variable which corresponds to the full path and file name of the\r\nscript that invoked the current command.\r\nFig.11 Stage-2  GoogleChromeUpdateHandlerx64.vbs dropped in the startup folder\r\nOn every system startup, the “GoogleChromeUpdateHandlerx64.vbs” script is executed from the startup folder,\r\nwhich initializes the WScript.Shell object and the Powershell execution policy with the RemoteSigned parameter\r\nto execute an unsigned Stage-2 Powershell script from the specified path. Therefore, the Stage-2 script,\r\nlcscgt0mss.ps1, is executed every time the system is restarted by dropping the script and setting the\r\n$PSCommandPath to the file name of the script that invoked the current command at runtime.\r\nThe second part of the Stage-2 script decrypts another PowerShell script in-memory and executes it, as shown in\r\nthe screenshot below.\r\nFig.12 Stage-2 Decryption (in-memory) of Stage-3 Powershell script\r\nThe script begins by initializing an encrypted integer stream called $rawData, which is passed on to a function\r\ncalled \"IntegerToBytes()\" along with the string argument $sKey \"Qoepl10Msple1VCmle\". Inside the function, a\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 5 of 17\n\n$dataBuffer is initialized to store the decrypted output, and a decryption loop is performed as follows below.\r\nDecryption logic: \r\nThe Decryption loop sets up a counter variable $i=0 and increments it to the length of the $rawData stream\r\n(3473)  by 1 upon completion of each loop. This is the decryption logic:\r\nThe first character of the $sKey, i.e., Q is converted to its corresponding character code using\r\nAscW($sKey) and stored in $ascwKey = “81”, only this is used for decryption\r\nThen, the encrypted integer stream is accessed one digit at a time and divided by the key length multiplied\r\nby 128 = $iData[$i] / ($sKey.Length * 128) and saved into the $deBuff variable\r\nThis $deBuff variable is then subtracted from the $ascwKey i.e “81” and stored in the $decData variable.\r\nThe $decData variable is the decrypted byte which is added into the $dataBuffer till the completion of the\r\nloop\r\nOnce the loop is completed, the script converts the $dataBuffer to ArrayList object in proper sequence by using\r\nthe $dataBuffer.ToArray() function and returns the final value. The final array is then converted to string using\r\nUTF8.GetString(final_value) and then stored in a variable $PDF which is another powershell script. \r\nFinally, the Stage-2 PowerShell Script executes and loads the decrypted Stage-3 PowerShell Script into memory\r\nusing Invoke-Expression.\r\nStage-3: In-memory decrypted Powershell script\r\nUpon execution, the Stage-3 PowerShell script is decrypted with a key and run via Invoke-Expression.\r\nSubsequently, the script generates an XMLHTTP object to send arbitrary HTTP requests and receive their\r\nresponses.\r\nAdditionally, the script initializes the following configurations related to the download server:\r\n$IP = “185[.]81[.]157[.]59”\r\n$Port = “3333”\r\n$Splitter = “|V|”\r\n$ErrorActionPreference = “Silently Continue\r\nFig.13 Stage-3 In-memory decrypted Powershell script download server configuration\r\nThe \"DropToStartUp()\" function is executed by the Stage-3 PowerShell script after initialization. This function is\r\nthe same one used in the Stage-2 script, which converts the byte stream to a string and writes it to the startup\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 6 of 17\n\nfolder with the name GoogleChromeUpdateHandler.vbs. Consequently, when the system reboots, the\r\nGoogleChromeUpdateHandler.vbs script automatically executes the Stage-3 PowerShell script by initializing\r\nthe Wscript.Shell object. The $PSCommandPath variable, which contains the path of the invoking script, is\r\nalready concatenated into the script at runtime.\r\nFig.14 GoogleChromeUpdateHandler.vbs dropped in the startup folder for persistence\r\nThe \"INF()\" function is used to gather system information in the Stage-3 PowerShell script. Firstly, it retrieves the\r\nuniversally unique identifier (UUID) of the system by passing the computer name through the\r\n$env:computername environment variable to the \"HWID()\" function. The \"HWID()\" function executes a WMI\r\nObject query (\"get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID\") to\r\nfetch the UUID and converts it into a string using the \"ToString()\" method. Next, the UUID is parsed to\r\nconcatenate only the first two values while removing the \"-\" splitter from the identifier. Finally, the concatenated\r\nUUID is returned.\r\nFig.15 Fetches system UUID via WMI object queries\r\nAdditionally, in the Stage-3 Powershell script, the operating system's name, version, and architecture (32-bit or\r\n64-bit) are collected using the following WMI object queries: Get-WMIObject Win32_OperatingSystem.Name\r\n(which splits the output string via “|”) and Get-WMIObject Win32_OperatingSystem.OSArchitecture. The\r\nscript also collects the computer name and username of the system. Once all of the necessary information is\r\ncollected, it is arranged and concatenated with specific constant strings in a particular order, as displayed in the\r\nscreenshot below.\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 7 of 17\n\nFig.16 System information gathering and concatenation\r\nAfter gathering system information, the Stage-3 Powershell script arranges the data and stores it in the $INFO\r\nvariable in the following format:\r\nNovo_\\Windows Defender\\Yes\\Yes\\FALSE\\\r\nNext, the script calls the HTTP() function to download the Stage-4 Powershell script from the Download Server.\r\nThe HTTP() function takes two arguments: the first is set to “Vre” and the second is null, as shown in the\r\nscreenshot below.\r\nFig.17 “Vre” parameter passed on to the HTTP function\r\nThe HTTP() Function then sends across a HTTP request via the XMLHttpRequest.Open() with following\r\nparameters:\r\n- Method: POST\r\n- Url: http://$IP:Port/Vre (Download Server IP and Port)\r\nWhere in this case $IP = “185[.]81[.]157[.]59” and $Port = “3333”\r\nNote: The value of the $IP and $Port keeps on changing as per the final payload to be executed on the infected\r\nmachine\r\nFurther, it sets up the user-agent via the XMLHttpRequest.setRequestHeader() with the $INFO variable, which\r\nwas assigned to the formatted version of the gathered system information defined previously. Then, the POST\r\nrequest is sent across with the required parameters to the download server in order to download the next stage, the\r\nStage-4 Powershell script. The response is then encapsulated and converted into string and returned to the\r\nprevious function for parsing as shown in the screenshot below.\r\n Fig.18 Downloads the Stage-4 Powershell script from the download server\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 8 of 17\n\nThe following request is then sent to the download server:\r\nFig.19 Request to the download server\r\nFurther, the downloaded data, i.e., the Stage-4 Powershell script, is passed to the Split() function along with the\r\nseparator $Splitter = “|V|'' which was initialized before. The Split() function then separates the downloaded data\r\ninto two parts:\r\n  “TR|V|Add-Type -AssemblyName System.Windows.FormsAdd-Type -AssemblyName..”\r\nThe split function then separates the script in two parts. One is “TR”, which is the command from the downloader\r\nserver, and second is the Stage-4 Powershell script.  The first part, i.e., index “0”, the command from the\r\ndownloader server, is then passed on to the switch statement which consists of three conditions as shown in the\r\nscreenshot below.\r\nswitch($command){\r\nif $command = “TR” - Perform the Malicious Routine\r\nif $command = “Cl” - Exit the code\r\nif $command = “Un” - Exit the code\r\n}\r\nFig.20 Switch statement as per the command input\r\nTherefore, if the command from the download server equals “TR” after splitting the complete downloaded data\r\ninto two parts, the malicious code routine is executed.\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 9 of 17\n\nThis code routine initially generates a random GUID using the NewGuid function then removes the ‘-’ from the\r\nGuid and concatenates it with “.PS1”. This becomes the FileName for the Stage-4 Powershell script eg.\r\n0d0c2fb5b767451788a2751ca5ebea2a.PS1. The Filename is then concatenated with the system’s temp path which\r\nbecomes the file path for the Powershell script, and then the Stage-4 Powershell script is written using\r\nWriteAllText() function at the temp path.\r\nFurther, in order to maintain persistence, the same technique used in the previous “DropToStartUp()” function is\r\nimplemented where the byte stream is converted to string and then written in the startup folder with the file named\r\nas WinLogonUpdate.vbs in this case. Therefore whenever the system is restarted, the Stage-4 Powershell script is\r\nexecuted automatically by the system using the WinLogonUpdate.vbs script by initially creating an Wscript.Shell\r\nObject. Then the Stage-4 Powershell Script, as the Temp File path of the Powershell script, is updated at runtime\r\nwhile dropping the script as shown in the screenshot below.\r\nFig.21 Dropping of Stage-4 Powershell script in the temp path along with persistence\r\nOnce the persistence is laid out, the Stage-4 Powershell script from the download server is executed from the temp\r\npath via invocation of Powershell.exe with hidden window style and the execution policy is set to RemoteSigned.\r\nAt the end, Stage-3 Powershell script sleeps for “3000” milliseconds and then closes off.\r\nStage-4 - The Final Stage - RAT Loader\r\nThe Stage-4 Powershell script is the “Final Stage - RAT Loader” and has been used effectively by the “Snip3\r\nCrypter crew” as the final loader in the infection chain which delivers and executes numerous RAT families onto\r\ntarget machines. The loader compiles the RunPE source code at runtime which is embedded in the Powershell\r\nscript as a compressed GZIP byte stream in order to perform Process Hollowing to execute the RAT.\r\nImplementing this technique allows the loader to stay under the radar and evade detection mechanisms in place.\r\nThe loader initially executes the INSTALL function which is the same as the “DropToStartUp()” function\r\nexplained previously. The function writes the following VBS script in the startUp folder by first converting the\r\nbyte stream into string and then writing it using WriteAllText() and concatenating the Snip3 Crypter File path at\r\nruntime.\r\nFig.22 VBS script dropped in startup folder in order to maintain persistence \r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 10 of 17\n\nFurther, the most important function of the Snip3 Crypter, the CodeDom(), is executed. The CodeDom function\r\ntakes three arguments. The first one is the GZIP compress RUNPE code in byte format, the second is the type\r\nobject, “Git.Repository”, where Git is the namespace and Repository is the class name, and the third, “Execute”, is\r\nthe method to be invoked  after sleeping for 2000 milliseconds as shown in the screenshot below.\r\nFig.23 Execution of the CodeDom() function\r\nUpon being executed, the CodeDom function initializes the CodeDom compiler.  a .NET API which allows devs\r\nto programmatically compile code using the .NET compilers where the version is set to v4 in this case. Along with\r\nthe version, the compiler parameters such as CompilerOptions and IncludeDebugInformation are initiated during\r\nthe compilation process shown in the screenshot below\r\nFig.24 CodeDom compiler initialization\r\nPost-initialization of the CodeDom Compiler the GZIP compressed RunPE byte stream is decompressed via the\r\nDecompress($RunPE) function. This uses the System.IO.Compression.GzipStream with the “Decompress”\r\nparameters with input as the GZIP compressed RunPE byte stream, as shown below.\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 11 of 17\n\nFig.25 GZIP Decompression of RunPE Byte Stream\r\nOnce the RunPE Byte Stream is decompressed, it’s then compiled dynamically at runtime using\r\nCompileAssemblyFromSource via the CodeDom API, where the argument to the functions is the Decompressed\r\nRunPE Byte stream. During the compilation, the CSC.exe, i.e., the C# command line compiler process, is\r\nspawned, and the compiler creates a temporary CS source code file in the temp directory. After analyzing the\r\ndropped source code file, the ThreatLabz team was able to formulate that “RunPE” technique is been used in\r\norder to inject the final RAT payload into remote process via process hollowing, as shown in the following\r\nscreenshot.\r\nFig.26 Runtime compilation of RunPe source code using CodeDom\r\nFurther, the decoding routine of the final RAT payload takes place where fthe URL encoded payload was decoded\r\nto a byte array using the UrlDecodeToBytes() function. Then, the output is passed on to the Decompress()\r\nfunction where the URL-decoded byte array is GZIP decompressed. The GZIP decompressed file is the final\r\nexecutable RAT file with the “MZ” header, as shown in the following screenshot.\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 12 of 17\n\nFig.28 Runtime compilation of RunPe source code using CodeDom\r\nOnce the RunPE source has been dynamically compiled and the RAT payload has been decoded, the Snip3\r\nCrypter reflectively loads the compiled RunPE loader in-memory via an Invoke() function where the executed\r\nmethod is “execute” and the arguments are the path to AppLaunch.exe gathered via GetRuntimeDirectory().\r\nFig.29 Reflective loading of the compiled RunPE payload alongside the arguments\r\nThe reflectively loaded RunPE payload then processes the following two arguments provided by the Snip3\r\nCrypter:\r\nPath to AppLaunch.exe: Target process for process hollowing\r\nRAT payload: The final RAT executable\r\nFig.30 Arguments to the reflectively loaded RunPE Payload\r\nFurther, the RunPE payload then performs process hollowing in order to inject the RAT payload into the remote\r\nprocess “AppLaunch.exe” by creating the target process via CreateProcessA() in a suspended state.\r\nThe payload then unmaps or empties out the target process memory via ZwUnMapViewOfSection() \r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 13 of 17\n\nThen, memory is allocated in the remote target process depending on the size of the payload via VirtualAllocEx(),\r\nthen the Final RAT Payload is written at the allocated memory location via WriteProcessMemory().\r\nTowards the end of the process hollowing, the threat context is reconfigured via GetThreadContext() and\r\nSetThreatContext() and the SetThreadContext() post reconfiguration points to the beginning of the malicious\r\ncode.\r\nAt last, the RunPE payload simply resumes the thread and the final RAT payload is executed in the remote process\r\n“AppLaunch.exe” injected via process hollowing.\r\nFurther, the ThreatLabz team dumped the RAT payload from the remote process “AppLaunch.exe” then extracted\r\nthe configuration as shown in the following screenshot. By analyzing the configuration, they were able to attribute\r\nthe malware as “DcRat” as per the mutex value: DcRatMutex_qwqdanchun and the certificate information:\r\nDcRAT Server as seen in the extracted configuration.\r\nCommand and control for DcRAT = crazydns[.]linkpc[.]net:5900\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 14 of 17\n\nFig.32 DcRAT Extracted Configuration\r\nThe ThreatLabz team analyzed multiple different Snip3 Crypter’s delivering DcRAT where the loader was almost\r\nsimilar and found that the changes were made only in the case of the target process selected for hollowing such as\r\n“RegSvcs.exe”/“InstallUtil.exe”/”RegAsm.exe”. In some cases, the RAT decoding routine consists of the\r\nStrReverse() function along with the URL UrlDecodeToBytes() function, which would first reverse the URL-encoded string and then URl decode it in order to deliver the final DcRAT payload.\r\nFig.33  StrReverse() and different Injection target Process been used for delivering the DcRAT \r\nFurther, the ThreatLabz team also came across samples leveraging the Snip3 crypter with new TTPs in order to\r\ndeliver “QuasarRAT” on the targeted systems with the similar infection chain as explained before.\r\nIn this case, the final Snip3 crypter RAT loader is downloaded from a different download server:\r\n185[.]81[.]157[.]172:6594/Vre\r\nFig.34 Download server for QuasarRAT delivery\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 15 of 17\n\nThe downloaded Snip3 RAT loader is exactly the same as the previous ones including their respective decryption\r\nand loader routines. Here, only the target process for hollowing is “RegAsm.exe” as shown in the screenshot\r\nbelow.\r\nFig.35 Snip3 RAT loader for executingQuasarRAT \r\nPost this the QuasarRAT payload is injected into the “RegAsm.exe” using the Dynamically compiled RunPE code\r\nwhich internally uses Process Hollowing as a Process Injection mechanism.\r\nFurther, the ThreatLabz team dumped the RAT payload from “RegAsm.exe” and extracted the configuration\r\nwhich helped them in the Attribution by analyzing the Mutex value: “QSR_MUTEX_M611SwpmZ8q66BUDI”\r\nand the autorun_regkey_name: “Quasar Client Startup” leading to the conclusion that the Snip3 Crypter was\r\nbeing leveraged in order to deliver QuasarRAT on the targeted machines.\r\nCommand and control server for QuasarRAT: 185[.]81[.]157[.]203:1111\r\nFig.37 QuasarRAT configuration\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 16 of 17\n\nExplore more Zscaler blogs\r\nSource: https://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nhttps://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://www.zscaler.com/blogs/security-research/snip3-crypter-reveals-new-ttps-over-time"
	],
	"report_names": [
		"snip3-crypter-reveals-new-ttps-over-time"
	],
	"threat_actors": [],
	"ts_created_at": 1775434895,
	"ts_updated_at": 1775826763,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/06adc50aef05fea02d1d41b52fe51c1cde44c542.pdf",
		"text": "https://archive.orkl.eu/06adc50aef05fea02d1d41b52fe51c1cde44c542.txt",
		"img": "https://archive.orkl.eu/06adc50aef05fea02d1d41b52fe51c1cde44c542.jpg"
	}
}