{
	"id": "25c872ff-bb5f-42cc-b7ad-17f8b2ebab5f",
	"created_at": "2026-04-06T01:31:21.245834Z",
	"updated_at": "2026-04-10T03:21:29.414443Z",
	"deleted_at": null,
	"sha1_hash": "e260b127f912b40511a01426b3dabe8ff49496a5",
	"title": "A Red Teamer’s Guide to GPOs and OUs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1181304,
	"plain_text": "A Red Teamer’s Guide to GPOs and OUs\r\nPublished: 2018-04-02 · Archived: 2026-04-06 00:41:32 UTC\r\nIntro\r\nActive Directory is a vast, complicated landscape comprised of users, computers, and groups, and the complex,\r\nintertwining permissions and privileges that connect them. The initial release of BloodHound focused on the\r\nconcept of derivative local admin, then BloodHound 1.3 introduced ACL-based attack paths. Now, with the\r\nrelease of BloodHound 1.5, pentesters and red-teamers can easily find attack paths that include abusing control of\r\nGroup Policy, and the objects that those Group Policies effectively apply to.\r\nIn this blog post, I’ll recap how GPO (Group Policy Object) enforcement works, how to use BloodHound to find\r\nGPO-control based attack paths, and explain a few ways to execute those attacks.\r\nPrior Work\r\nLucas Bouillot and Emmanuel Gras included GPO control and OU structure in their seminal work, “Chemins de\r\ncontrôle en environnement Active Directory”. They used an attack graph to map which principals could take\r\ncontrol of GPOs, and which OUs those GPOs applied to, then chased that down to the objects affected by those\r\nGPOs. We learned a lot from Lucas and Emannuel’s white paper (in French), and I’d highly recommend you read\r\nit as well.\r\nThere are several important authors and resources we leaned on when figuring out how GPO works, in no\r\nparticular order: the Microsoft Group Policy team’s posts on TechNet, Sean Metcalf’s work at adsecurity.org, 14-\r\ntime Microsoft MVP “GPO Guy” Darren Mar-Elia, Microsoft’s Group Policy functional specification, and last but\r\ncertainly not least, Will Schroeder’s seminal blog post on Abusing GPO Permissions. Special extra thanks to\r\nDarren Mar-Elia for answering a lot of my questions about Group Policy. Thanks, Darren! Other resources and\r\nreferences are linked at the bottom of this blog post.\r\nThe Moving Parts of Group Policy\r\nThere’s no two ways about it: GPO enforcement is a complicated beast with a lot of moving parts. With that said,\r\nlet’s start at the very basics with the vocabulary used in the rest of the post, and build up to explaining how those\r\nmoving parts interact with one another:\r\nGPO: A Group Policy Object. When an Active Directory domain is first created, two GPOs are created as well:\r\n“Default Domain Policy” and “Default Domain Controllers”. GPOs contain sets of policies that affect computers\r\nand users. For example, you can use a GPO policy to control the Windows desktop background on computers.\r\nGPOs are visible in the Group Policy Management GUI here:\r\nhttps://wald0.com/?p=179\r\nPage 1 of 15\n\nAbove: The list of GPOs in our test domain.\r\nTechnically, “Default Domain Controllers Policy” is the display name of the GPO, while the name of the GPO is a\r\nGPO curly braced “GUID”. I put “GUID” in quotation marks because this identifier is not actually globally\r\nunique. The “Default Domain Controllers Policy” in every Active Directory domain will have the same “name”\r\n(read: curly braced GUID): {6AC1786C-016F-11D2-945F-00C04fB984F9}. For this reason, GPOs have an\r\nadditional parameter called objectguid, which actually is globally unique. The policy files for any given GPO\r\nreside in the domain SYSVOL at the policy’s gpcfilesyspath (ex: \\\\contoso.local\\sysvol\\contoso.local\\Policies\\\r\n{6AC1786C-016F-11D2-945F-00C04fB984F9}).\r\nhttps://wald0.com/?p=179\r\nPage 2 of 15\n\nAbove: The relevant properties of the “Default Domain Controllers Policy” GPO, and that GPO’s policy files\r\nlocation in the SYSVOL.\r\nOU: An Organizational Unit. According to Microsoft’s TechNet, OUs are “general-purpose container[s] that can\r\nbe used to group most other object classes together for administrative purposes”. Basically, OUs are containers\r\nthat you place principals (users, groups, and computers) into. Organizations will commonly use OUs to organize\r\nprincipals based on department and/or geographic location. Additionally, OUs can of course by nested within\r\nother OUs. This usually results in a relatively complex OU tree structure within a domain, which can be difficult\r\nto navigate without first being very familiar with the tree. You can see OUs in the ADUC (Active Directory Users\r\nand Computers) GUI. In the below screenshot, “ContosoUsers” is a child OU of the CONTOSO.LOCAL domain,\r\n“Helpdesk” is a child OU within  the “ContosoUsers” OU, and “Alice Admin” is a child user of the “Helpdesk”\r\nOU:\r\nhttps://wald0.com/?p=179\r\nPage 3 of 15\n\nAbove: The Alice Admin user within the OU tree.\r\nGpLink: A Group Policy Link. GPOs can be “linked” to domains, sites, and OUs. By default, a GPO that is\r\nlinked to an OU will apply to the child objects of that OU. For example, the “Default Domain Policy” GPO is\r\nlinked, by default, to the domain object, while the “Default Domain Controllers Policy” is linked, by default, to\r\nthe Domain Controllers OU. In the below screenshot, you can see that if we expand the “contoso.local” domain\r\nand the “Domain Controllers” OU, the GPOs linked to those objects appear below them:\r\nhttps://wald0.com/?p=179\r\nPage 4 of 15\n\nAbove: The “Default Domain Policy” is linked to the domain “contoso.local”. The “Default Domain\r\nControllers” policy is linked to the “Domain Controllers” OU.\r\nGpLinks are stored on the objects the GPO is linked to, on the attribute called “gplink”. The format of the\r\n“gplink” attribute value is [\u003cDistinguished name of the GPO\u003e;\u003c0 if the link is not enforced, 1 if the link is\r\nenforced\u003e]. You can easily enumerate those links with PowerView as in the example below:\r\nAbove: The “Default Domain Controllers Policy” GPO is linked to the “Domain Controllers” OU, and is not\r\nenforced.\r\nThose three pieces — GPOs, OUs, and GpLinks — comprise the major moving parts we’re working with. It’s\r\nimportant to know those three pieces well before understanding GPO enforcement logic and how to use\r\nBloodHound to find attack paths, so make sure you feel confident with those before continuing on. One last note:\r\nhttps://wald0.com/?p=179\r\nPage 5 of 15\n\nGPOs can also be linked to sites, but at this time we’re not including that due to complications site memberships\r\nand collection challenges.\r\nGPO Enforcement Logic\r\nNow that you know the basic moving parts, let’s look more closely at how they connect. GPO enforcement logic,\r\nvery briefly, works like this:\r\nGpLinks can be enforced, or not.\r\nOUs can block inheritance, or not.\r\nIf a GpLink is enforced, the associated GPO will apply to the linked OU and all child objects, regardless of\r\nwhether any OU in that tree blocks inheritance.\r\nIf a GpLink is not enforced, the associated GPO will apply to the linked OU and all child  objects, unless\r\nany OU within that tree blocks inheritance.\r\nThere are further complications on top of this, which we’ll get to later on. First though, let’s visualize the above\r\nrules regarding GpLink enforcement and OUs blocking inheritance. Recall earlier I had a user called Alice Admin\r\nwithin a HelpDesk OU. Instead of looking at that in ADUC, though, let’s start to think about this as a graph:\r\nAbove: Alice Admin within the domain/OU tree.\r\nThe domain object, Contoso.Local, is a container object. It contains the OU called ContosoUsers. The OU\r\nContosoUsers contains the OU HelpDesk. Finally, the OU HelpDesk contains the user Alice Admin.\r\nNow, let’s add our Default Domain Policy GPO into the mix. Recall from earlier that in my test domain, that GPO\r\nis linked to the domain object:\r\nAbove: The “Default Domain Policy” GPO is linked to the domain object.\r\nNow, in default circumstances, you can simply read from left to right to figure out that the Default Domain Policy\r\nwill apply to the user Alice Admin. The “default circumstance” here is that the GpLink relationship is not\r\nenforced, and that none of the containers in this path block inheritance. Let’s add that information to the above\r\ngraph:\r\nhttps://wald0.com/?p=179\r\nPage 6 of 15\n\nIn this circumstance, it doesn’t matter that the GpLink edge is not enforced, as none of the OUs block inheritance.\r\nIn our test domain, we have another OU under ContosoUsers called “Accounting”, with one user in that OU: Bob\r\nUser. For example’s sake, we’ll say that the Accounting OU does block inheritance. Let’s add that to our existing\r\ngraph:\r\nAgain, we can see that the Default Domain Policy GPO is linked to the domain object, and Bob User is contained\r\nwithin the OU tree under the domain object; however, because the OU “Accounting” blocks inheritance, and\r\nbecause the GpLink edge is not enforced, the Default Domain Policy will not apply to Bob User.\r\nStill with me? You’d be forgiven for being slightly confused at this point, but don’t worry, it gets worse!\r\nLet’s add another GPO to the mix and link it to the domain object as well, except this time we will enforce the\r\nGpLink:\r\nOur new GPO called “Custom Password Policy” is linked to the domain object, which again contains the entire\r\nOU tree under it. Now, because the GPLink is enforced, this policy will apply to all child objects in the OU tree,\r\nhttps://wald0.com/?p=179\r\nPage 7 of 15\n\nregardless of whether any of those OUs block inheritance. This means that the “Custom Password Policy” GPO\r\nwill apply to both “Alice Admin” and “Bob User”, despite the “Accounting” OU blocking inheritance.\r\nIn our experience, this information is going to cover 95%+ of situations you’ll run into in real enterprise networks;\r\nhowever, there are three more things to know about, which may impact you when abusing GPO control paths\r\nduring your pentests and red team assessments: WMI filtering, security filtering, and Group Policy link order and\r\nprecedence.\r\nWMI filtering allows administrators to further limit which computers and users a GPO will apply to, based\r\non whether a certain WMI query returns True or False. For example, when a computer is processing group\r\npolicy, it may run a WMI query that checks if the operating system is Windows 7, and only apply the group\r\npolicy if that query returns true. See Darren Mar-Elia’s excellent blog post for further details.\r\nSecurity filtering allows administrators to further limit which principals a GPO will apply to.\r\nAdministrators can limit the GPO to apply to specific computers, users, or the members of a specific\r\nsecurity group. By default, every GPO applies to the “Authenticated Users” principal, which includes any\r\nprincipal that successfully authenticates to the domain. For more details, see this post on the TechGenix\r\nsite.\r\nGroup Policy link order dictates which Group Policy “wins” in the event of conflicting, non-merging\r\npolicies. Imagine you have two “Password Policy” GPOs: one that requires users to change their password\r\nevery 30 days, and one that requires users to change their password every 60 days. Whichever policy is\r\nhigher in the precedence order is the policy that will “win”. The group policy client enforces this “win”\r\ncondition by processing policies in reverse order of precedence, so the highest precedence policy is\r\nprocessed last, and “wins”. Luckily, you don’t need to worry about this for almost every abuse primitive.\r\nFor more information, check out this blog post.\r\nLike I said above, our experience has been that in real enterprise networks, you won’t need to worry about WMI\r\nfiltering, security filtering, or GpLink order in 95% or more of the situations you run into, but I mention them so\r\nyou know where to start troubleshooting if your abuse actions aren’t working. We may try to roll those three items\r\ninto the BloodHound interface in the future. In the meantime, make sure your target computer and user objects\r\nwon’t be filtered out by WMI or security filters, or attempt to push an evil group policy that will be overruled by a\r\nhigher precedence policy.\r\nAnalysis with BloodHound\r\nFirst, make sure you are running at least BloodHound 1.5.1. Second, do your standard SharpHound collection like\r\nyou always have, but this time either do the “All” or “Containers” and “ACL” collection methods, which will\r\ncollect GPO ACLs and OU structure for you:\r\nC:\\\u003e SharpHound.exe -c All\r\nThen, import the resulting acls.csv, container_gplinks.csv, and container_structure.csv through the BloodHound\r\ninterface like normal. Now you’re ready to start analyzing outbound and inbound GPO control against objects.\r\nhttps://wald0.com/?p=179\r\nPage 8 of 15\n\nFor example, let’s take a look at our “Alice Admin” user. If we search for this user, then click on the user node,\r\nyou’ll see some new information in the user tab, including “Effective Inbound GPOs”:\r\nAbove: Two GPOs apply to Alice Admin.\r\nThe Cypher query that generates this number does the GpLink enforcement and OU blocking inheritance logic for\r\nyou, so you don’t need to worry about working that out yourself. Simply click on the number “2”, in this instance,\r\nto visualize the GPOs that apply to “Alice Admin”:\r\nAbove: How the two GPOs apply to Alice Admin.\r\nNotice the edge connecting “Default Domain Policy” to the “Contoso.Local” domain is dotted. This means that\r\nthis GPO is not enforced; however, all of the “Contains” edges are solid, meaning that none of those containers\r\nblock inheritance. Recall from earlier that unenforced GpLinks will only be affected by OUs that block\r\ninheritance, so in this case, the Default Domain Policy still applies to Alice Admin.\r\nhttps://wald0.com/?p=179\r\nPage 9 of 15\n\nAlso note that the edge connecting “Customer Password Policy” to the “Contoso.Local” domain is solid. This\r\nmeans that this GPO is enforced, and will therefore apply to all children objects regardless of whether any\r\nsubsequent containers block inheritance.\r\nWe can also see the flip side of this — what objects does any given GPO effectively apply to? First, let’s check out\r\nthe Custom Password Policy GPO:\r\nAbove: The Custom Password Policy GPO applies to 3 computers and 5 users.\r\nReminder: GPOs can only apply to users and computers, not security groups.\r\nBy clicking on the numbers, you can render the objects affected by this GPO, and how the GPO applies to those\r\nobjects. If we click the “5” next to “User Objects”, we get this graph:\r\nAbove: How the Customer Password Policy GPO applies to user objects.\r\nThere are two important things to point out here: again, the edge connecting the “Custom Password Policy” GPO\r\nto the “Contoso.Local” domain object is solid, meaning this GPO is enforced. Second, notice the edge connecting\r\nhttps://wald0.com/?p=179\r\nPage 10 of 15\n\nthe “Accounting” OU to the “Bob User” user is dotted, indicating the “Accounting” OU blocks inheritance. But,\r\nbecause the “Custom Password Policy” GPO is enforced, the OU blocking inheritance doesn’t matter, and will\r\nbe applied to the “Bob User” user anyway.\r\nCompare the above graph to the graph we get if we do the same for the “Default Domain Policy”:\r\nAbove: The users affected by the “Default Domain Policy” GPO.\r\nNotice how the “Bob User” user is no longer there? That’s because the “Default Domain Policy” GPO is not\r\nenforced. Because the “Accounting” OU blocks inheritance, that GPO will not apply to the “Bob User” user.\r\nAlright, let’s put it all together and see if we can find an attack path from “Bob User” to “Alice Admin”. In the\r\nBloodHound search bar, click the path finding icon, then select your source node and target node. Hit enter, and\r\nBloodHound will find and render an attack path, if one exists:\r\nhttps://wald0.com/?p=179\r\nPage 11 of 15\n\nAbove: The attack path from “Bob User” to “Alice Admin”.\r\nReading this graph from left to right, we can see that “Bob User” is in a group called “Accounting”, which is part\r\nof a group called “Group Policy Admins” (believe me when I say crazier things have happened in the wild, and\r\nremember this is a contrived example :). The “Group Policy Admins” group has, as you would imagine, full\r\ncontrol of the “Custom Password Policy” GPO. That GPO is then linked to the “Contoso.Local” domain. From\r\nhere we have a couple options – push an evil policy down to the “Administrator” user and take over “Alice\r\nAdmin” with an ACL based attack or just push an evil policy down directly to the “Alice Admin” user.\r\nAbusing GPO Control\r\nFinally, the most important part of this entire topic: how to actually take over computers and users with control\r\nover the GPOs that affect those users. For a bit of background and inspiration, read Will’s excellent blog post on\r\nabusing GPO rights, which contains information about the first proof-of-concept GPO abuse cmdlet that I’m\r\naware of, New-GPOImmediateTask.\r\nWhen people say “you can do anything with GPO”, they really mean it: you can do anything with GPO. Will and\r\nI put together this list of abuses against computers, including the policy location and abuse, just to give you a few\r\nideas:\r\nPolicy Location: Computer Configuration\\Preferences\\Control Panel Settings\\Folder Options\r\nAbuse: Create/alter file type associations, register DDE actions with those associations.\r\nPolicy Location: Computer Configuration\\Preferences\\Control Panel Settings\\Local Users and Groups\r\nAbuse: Add new local admin account.\r\nPolicy Location: Computer Configuration\\Preferences\\Control Panel Settings\\Scheduled Tasks\r\nAbuse: Deploy a new evil scheduled task (ie: PowerShell download cradle).\r\nhttps://wald0.com/?p=179\r\nPage 12 of 15\n\nPolicy Location: Computer Configuration\\Preferences\\Control Panel Settings\\Services\r\nAbuse: Create and configure new evil services.\r\nPolicy Location: Computer Configuration\\Preferences\\Windows Settings\\Files\r\nAbuse: Affected computers will download a file from the domain controller.\r\nPolicy Location: Computer Configuration\\Preferences\\Windows Settings\\INI Files\r\nAbuse: Update existing INI files.\r\nPolicy Location: Computer Configuration\\Preferences\\Windows Settings\\Registry\r\nAbuse: Update specific registry keys. Very useful for disabling security mechanisms, or triggering code\r\nexecution in any number of ways.\r\nPolicy Location: Computer Configuration\\Preferences\\Windows Settings\\Shortcuts\r\nAbuse: Deploy a new evil shortcut.\r\nPolicy Location: Computer Configuration\\Policies\\Software Settings\\Software installation\r\nAbuse: Deploy an evil MSI. The MSI must be available to the GP client via a network share.\r\nPolicy Location: Computer Configuration\\Policies\\Windows Settings\\Scripts (startup/shutdown)\r\nAbuse: Configure and deploy evil startup scripts. Can run scripts out of GPO directory, can also run\r\nPowerShell commands with arguments\r\nPolicy Location: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local\r\nPolicies\\Audit Policy\r\nAbuse: Modify local audit settings. Useful for evading detection.\r\nPolicy Location: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\User\r\nRights Assignment\\\r\nAbuse: Grant a user the right to logon via RDP, grant a user SeDebugPrivilege, grant a user the right to\r\nload device drivers, grant a user seTakeOwnershipPrivilege. Basically, take over the remote computer\r\nwithout ever being an administrator on it.\r\nPolicy Location: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Registry\r\nAbuse: Alter DACLs on registry keys, grant yourself an extremely hard to find backdoor on the system.\r\nPolicy Location: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Windows Firewall\r\nAbuse: Manage the Windows firewall. Open up ports if they’re blocked.\r\nPolicy Location: Computer Configuration\\Preferences\\Windows Settings\\Environment\r\nAbuse: Add UNC path for DLL side loading.\r\nPolicy Location: Computer Configuration\\Preferences\\Windows Settings\\Files\r\nAbuse: Copy a file from a remote UNC path.\r\nSo, that’s all well and good, but how do we actually take these actions? Currently, you’ve got two options:\r\ndownload and install the Group Policy Management Console and use the GPMC GUI to modify the relevant GPO\r\nor manually craft the relevant policy file and correctly modify the GPO and gpt.ini file.\r\nhttps://wald0.com/?p=179\r\nPage 13 of 15\n\nAs an example, let’s say you want to push a new immediate scheduled task to a computer or user. My current\r\nunderstanding (which is definitely subject to correction), based on testing and the Microsoft Group Policy\r\nPreferences functional spec, follows:\r\nWhenever a group policy client (user or computer) checks for updated group policy, they will go through several\r\nsteps to collect and apply Group Policy to themselves. The client will check whether the remote version of the\r\nGPO is greater than the locally cached version of that GPO (unless gpupdate /force is used). The remote version of\r\nthe GPO is stored in two locations:\r\n1. As an integer value for the versionNumber attribute on the Group Policy Object itself.\r\n2. As the same integer in the GPT.INI file, located at \\\\\u003cdomain.com\u003e\\Policies\\\u003cgpo name\u003e\\GPT.ini. Note\r\nthat the “name” of the GPO is not the display name. For instance, the “name” for the Default Domain\r\nPolicy is {6AC1786C-016F-11D2-945F-00C04fB984F9}.\r\nIf the remote GPO version number is greater than the locally cached version, the group policy client will continue,\r\nanalyzing which policies and/or preferences it needs to search for in the relevant SYSVOL directory. For Group\r\nPolicy preferences (which scheduled tasks fall under), the group policy client will check to see which Client-Side\r\nExtensions (CSEs) exist as part of the “gPCMachineExtensionNames” and “gPCUserExtensionNames” attributes.\r\nAccording to the Microsoft Group Policy Preferences functional spec, CSE GUIDs “enable a specific client-side\r\nextension on the Group Policy client to be associated with policy data that is stored in the logical and physical\r\ncomponents of a Group Policy Object (GPO) on the Group Policy server, for that particular extension.” The CSE\r\nGUIDs for Immediate Scheduled tasks, as they would be stored in the “gPCMachineExtensionNames” attribute,\r\nare:\r\n[{00000000-0000-0000-0000-000000000000}{79F92669-4224-476C-9C5C-6EFB4D87DF4A}{CAB54552-DEEA-4691-817E\r\nAnd in a slightly more readable format:\r\n[\r\n {00000000-0000-0000-0000-000000000000}\r\n {79F92669-4224-476C-9C5C-6EFB4D87DF4A}\r\n {CAB54552-DEEA-4691-817E-ED4A4D1AFC72}\r\n]\r\n[\r\n {AADCED64-746C-4633-A97C-D61349046527}\r\n {CAB54552-DEEA-4691-817E-ED4A4D1AFC72}\r\n]\r\nThis translates to the following:\r\n[\r\n {Core GPO Engine}\r\n {Preference Tool CSE GUID Local users and groups}\r\n {Preference Tool CSE GUID Scheduled Tasks}\r\nhttps://wald0.com/?p=179\r\nPage 14 of 15\n\n]\r\n[\r\n {Preference CSE GUID Scheduled Tasks}\r\n {Preference Tool CSE GUID Scheduled Tasks}\r\n]\r\nOnce the group policy client understands that there are some scheduled tasks that apply to it, it will search for a\r\nfile in the GP directory called ScheduledTasks.xml. That file exists in a predictable location:\r\n\\\\\u003cdomain.com\u003e\\sysvol\\\u003cdomain.com\u003e\\Policies\\\u003cgpo-name\u003e\\Machine\\Preferences\\ScheduledTasks.xml\r\nFinally, the group policy client will parse the ScheduledTasks.xml and register the task locally.\r\nThat’s how the process works, as I understand it. There is still a lot of work to be done on crafting scripts to\r\nautomate the GPO abuse process, as installing GPMC is rarely a great option while on a red team assessment. If\r\never there were a call to arms, this is it: we’ll continue working on creating scripts that reliably automate GPO\r\ncontrol abuse, but are equally as excited to see what people in the community can come up with as well.\r\nConclusion\r\nAs Rohan mentioned in his post, BloodHound 1.5 represents a pretty big milestone for the BloodHound project.\r\nBy adding in GPOs and OU structure, we’re greatly increasing the scope of Active Directory attack surface you\r\ncan easily map out with BloodHound. In a future blog post, I’ll focus more on the defensive side of things,\r\nshowing how defenders can use BloodHound to analyze and reduce the attack surface in AD now that we’re\r\ntracking GPOs and OU structure.\r\nBloodHound is available free and open source on GitHub at https://github.com/BloodHoundAD/BloodHound\r\nYou can join us on Slack at the official BloodHound Gang Slack here: https://bloodhoundgang.herokuapp.com/\r\nAlso published on Medium.\r\nSource: https://wald0.com/?p=179\r\nhttps://wald0.com/?p=179\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://wald0.com/?p=179"
	],
	"report_names": [
		"?p=179"
	],
	"threat_actors": [],
	"ts_created_at": 1775439081,
	"ts_updated_at": 1775791289,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e260b127f912b40511a01426b3dabe8ff49496a5.pdf",
		"text": "https://archive.orkl.eu/e260b127f912b40511a01426b3dabe8ff49496a5.txt",
		"img": "https://archive.orkl.eu/e260b127f912b40511a01426b3dabe8ff49496a5.jpg"
	}
}