{
	"id": "2f8300f3-388d-4237-b4d6-d900706e7cfd",
	"created_at": "2026-04-06T00:19:21.116074Z",
	"updated_at": "2026-04-10T03:35:21.50272Z",
	"deleted_at": null,
	"sha1_hash": "a84f65c0f6e969e52da623c045a1c2609f9fd210",
	"title": "Policies and permissions in AWS Identity and Access Management",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 120461,
	"plain_text": "Policies and permissions in AWS Identity and Access Management\r\nArchived: 2026-04-05 19:25:18 UTC\r\nManage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles)\r\nor AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their\r\npermissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in\r\nthe policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON\r\ndocuments. AWS supports seven types of policies: identity-based policies, resource-based policies, permissions\r\nboundaries, AWS Organizations service control policies (SCPs), AWS Organizations resource control policies\r\n(RCPs), access control lists (ACLs), and session policies.\r\nIAM policies define permissions for an action regardless of the method that you use to perform the operation. For\r\nexample, if a policy allows the GetUser action, then a user with that policy can get user information from the AWS\r\nManagement Console, the AWS CLI, or the AWS API. When you create an IAM user, you can choose to allow\r\nconsole or programmatic access. If console access is allowed, the IAM user can sign in to the console using their\r\nsign-in credentials. If programmatic access is allowed, the user can use access keys to work with the CLI or API.\r\nPolicy types\r\nThe following policy types, listed in order from most frequently used to less frequently used, are available for use\r\nin AWS. For more details, see the sections below for each policy type.\r\nIdentity-based policies – Attach managed and inline policies to IAM identities (users, groups to which\r\nusers belong, or roles). Identity-based policies grant permissions to an identity.\r\nResource-based policies – Attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant\r\npermissions to the principal that is specified in the policy. Principals can be in the same account as the\r\nresource or in other accounts.\r\nPermissions boundaries – Use a managed policy as the permissions boundary for an IAM entity (user or\r\nrole). That policy defines the maximum permissions that the identity-based policies can grant to an entity,\r\nbut does not grant permissions. Permissions boundaries do not define the maximum permissions that a\r\nresource-based policy can grant to an entity.\r\nAWS Organizations SCPs – Use an AWS Organizations service control policy (SCP) to define the\r\nmaximum permissions for IAM users and IAM roles within accounts in your organization or organizational\r\nunit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to IAM\r\nusers or IAM roles within the account. SCPs do not grant permissions.\r\nAWS Organizations RCPs – Use an AWS Organizations resource control policy (RCP) to define the\r\nmaximum permissions for resources within accounts in your organization or organizational unit (OU).\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 1 of 10\n\nRCPs limit permissions that identity-based and resource-based policies can grant to resources in accounts\r\nwithin your organization. RCPs do not grant permissions.\r\nAccess control lists (ACLs) – Use ACLs to control which principals in other accounts can access the\r\nresource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the\r\nonly policy type that does not use the JSON policy document structure. ACLs are cross-account\r\npermissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to\r\nentities within the same account.\r\nSession policies – Pass advanced session policies when you use the AWS CLI or AWS API to assume a\r\nrole or a federated user. Session policies limit the permissions that the role or user's identity-based policies\r\ngrant to the session. Session policies limit permissions for a created session, but do not grant permissions.\r\nFor more information, see Session Policies.\r\nIdentity-based policies\r\nIdentity-based policies are JSON permissions policy documents that control what actions an identity (users,\r\ngroups of users, and roles) can perform, on which resources, and under what conditions. Identity-based policies\r\ncan be further categorized:\r\nManaged policies – Standalone identity-based policies that you can attach to multiple users, groups, and\r\nroles in your AWS account. There are two types of managed policies:\r\nAWS managed policies – Managed policies that are created and managed by AWS.\r\nCustomer managed policies – Managed policies that you create and manage in your AWS account.\r\nCustomer managed policies provide more precise control over your policies than AWS managed\r\npolicies.\r\nInline policies – Policies that you add directly to a single user, group, or role. Inline policies maintain a\r\nstrict one-to-one relationship between a policy and an identity. They are deleted when you delete the\r\nidentity.\r\nTo learn how to choose between managed and inline policies, see Choose between managed policies and inline\r\npolicies.\r\nResource-based policies\r\nResource-based policies are JSON policy documents that you attach to a resource such as an Amazon S3 bucket.\r\nThese policies grant the specified principal permission to perform specific actions on that resource and defines\r\nunder what conditions this applies. Resource-based policies are inline policies. There are no managed resource-based policies.\r\nTo enable cross-account access, you can specify an entire account or IAM entities in another account as the\r\nprincipal in a resource-based policy. Adding a cross-account principal to a resource-based policy is only half of\r\nestablishing the trust relationship. When the principal and the resource are in separate AWS accounts, you must\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 2 of 10\n\nalso use an identity-based policy to grant the principal access to the resource. However, if a resource-based policy\r\ngrants access to a principal in the same account, no additional identity-based policy is required. For step-by step\r\ninstructions for granting cross-service access, see IAM tutorial: Delegate access across AWS accounts using IAM\r\nroles.\r\nThe IAM service supports only one type of resource-based policy called a role trust policy, which is attached to an\r\nIAM role. An IAM role is both an identity and a resource that supports resource-based policies. For that reason,\r\nyou must attach both a trust policy and an identity-based policy to an IAM role. Trust policies define which\r\nprincipal entities (accounts, users, roles, and federated users) can assume the role. To learn how IAM roles are\r\ndifferent from other resource-based policies, see Cross account resource access in IAM.\r\nTo see which other services support resource-based policies, see AWS services that work with IAM. To learn more\r\nabout resource-based policies, see Identity-based policies and resource-based policies. To learn whether principals\r\nin accounts outside of your zone of trust (trusted organization or account) have access to assume your roles, see\r\nWhat is IAM Access Analyzer?.\r\nIAM permissions boundaries\r\nA permissions boundary is an advanced feature in which you set the maximum permissions that an identity-based\r\npolicy can grant to an IAM entity. When you set a permissions boundary for an entity, the entity can perform only\r\nthe actions that are allowed by both its identity-based policies and its permissions boundaries. If you specify a role\r\nsession or user in the principal element of a resource-based policy, an explicit allow in the permission boundary is\r\nnot required. However, if you specify a role ARN in the principal element of a resource-based policy, an explicit\r\nallow in the permission boundary is required. In both cases, an explicit deny in the permission boundary is\r\neffective. An explicit deny in any of these policies overrides the allow. For more information about permissions\r\nboundaries, see Permissions boundaries for IAM entities.\r\nAWS Organizations service control policies (SCPs)\r\nIf you enable all features in an organization, then you can apply service control policies (SCPs) to any or all of\r\nyour accounts. SCPs are JSON policies that specify the maximum permissions for IAM users and IAM roles\r\nwithin accounts of an organization or organizational unit (OU). The SCP limits permissions for principals in\r\nmember accounts, including each AWS account root user. An explicit deny in any of these policies overrides an\r\nallow in other policies.\r\nFor more information about AWS Organizations and SCPs, see Service control policies (SCPs) in the AWS\r\nOrganizations User Guide.\r\nAWS Organizations resource control policies (RCPs)\r\nIf you enable all features in an organization, then you can use resource control policies (RCPs) to centrally apply\r\naccess controls on resources across multiple AWS accounts. RCPs are JSON policies that you can use to set the\r\nmaximum available permissions for resources in your accounts without updating the IAM policies attached to\r\neach resource that you own. The RCP limits permissions for resources in member accounts and can impact the\r\neffective permissions for identities, including the AWS account root user, regardless of whether they belong to\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 3 of 10\n\nyour organization. An explicit deny in any applicable RCP overrides an allow in other policies that might be\r\nattached to individual identities or resources.\r\nFor more information about AWS Organizations and RCPs including a list of AWS services that support RCPs, see\r\nResource control policies (RCPs) in the AWS Organizations User Guide.\r\nAccess control lists (ACLs)\r\nAccess control lists (ACLs) are service policies that allow you to control which principals in another account can\r\naccess a resource. ACLs cannot be used to control access for a principal within the same account. ACLs are\r\nsimilar to resource-based policies, although they are the only policy type that does not use the JSON policy\r\ndocument format. Amazon S3, AWS WAF, and Amazon VPC are examples of services that support ACLs. To\r\nlearn more about ACLs, see Access Control List (ACL) overview in the Amazon Simple Storage Service\r\nDeveloper Guide.\r\nSession policies\r\nSession policies are advanced policies that you pass as a parameter when you programmatically create a\r\ntemporary session for a role or an AWS STS federated user principal. The permissions for a session are the\r\nintersection of the identity-based policies for the IAM entity (user or role) used to create the session and the\r\nsession policies. Permissions can also come from a resource-based policy. An explicit deny in any of these policies\r\noverrides the allow.\r\nYou can create role session and pass session policies programmatically using the AssumeRole ,\r\nAssumeRoleWithSAML , or AssumeRoleWithWebIdentity API operations. You can pass a single JSON inline\r\nsession policy document using the Policy parameter. You can use the PolicyArns parameter to specify up to\r\n10 managed session policies. For more information about creating a role session, see Permissions for temporary\r\nsecurity credentials.\r\nWhen you create an AWS STS federated user principal session, you use the access keys of the IAM user to\r\nprogrammatically call the GetFederationToken API operation. You must also pass session policies. The resulting\r\nsession's permissions are the intersection of the identity-based policy and the session policy. For more information\r\nabout creating a federated user session, see Requesting credentials through a custom identity broker.\r\nA resource-based policy can specify the ARN of the user or role as a principal. In that case, the permissions from\r\nthe resource-based policy are added to the role or user's identity-based policy before the session is created. The\r\nsession policy limits the total permissions granted by the resource-based policy and the identity-based policy. The\r\nresulting session's permissions are the intersection of the session policies and the resource-based policies plus the\r\nintersection of the session policies and identity-based policies.\r\nA resource-based policy can specify the ARN of the session as a principal. In that case, the permissions from the\r\nresource-based policy are added after the session is created. The resource-based policy permissions are not limited\r\nby the session policy. The resulting session has all the permissions of the resource-based policy plus the\r\nintersection of the identity-based policy and the session policy.\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 4 of 10\n\nA permissions boundary can set the maximum permissions for a user or role that is used to create a session. In that\r\ncase, the resulting session's permissions are the intersection of the session policy, the permissions boundary, and\r\nthe identity-based policy. However, a permissions boundary does not limit permissions granted by a resource-based policy that specifies the ARN of the resulting session.\r\nPolicies and the root user\r\nThe AWS account root user is affected by some policy types but not others. You cannot attach identity-based\r\npolicies to the root user, and you cannot set the permissions boundary for the root user. However, you can specify\r\nthe root user as the principal in a resource-based policy or an ACL. A root user is still the member of an account. If\r\nthat account is a member of an organization in AWS Organizations, the root user is affected by SCPs and RCPs for\r\nthe account.\r\nOverview of JSON policies\r\nMost policies are stored in AWS as JSON documents. Identity-based policies and policies used to set permissions\r\nboundaries are JSON policy documents that you attach to a user or role. Resource-based policies are JSON policy\r\ndocuments that you attach to a resource. SCPs and RCPs are JSON policy documents with restricted syntax that\r\nyou attach to the AWS Organizations' organization root, organizational unit (OU), or an account. ACLs are also\r\nattached to a resource, but you must use a different syntax. Session policies are JSON policies that you provide\r\nwhen you assume a role or federated user session.\r\nIt is not necessary for you to understand the JSON syntax. You can use the visual editor in the AWS Management\r\nConsole to create and edit customer managed policies without ever using JSON. However, if you use inline\r\npolicies for groups or complex policies, you must still create and edit those policies in the JSON editor using the\r\nconsole. For more information about using the visual editor, see Define custom IAM permissions with customer\r\nmanaged policies and Edit IAM policies.\r\nWhen you create or edit a JSON policy, IAM can perform policy validation to help you create an effective policy.\r\nIAM identifies JSON syntax errors, while IAM Access Analyzer provides additional policy checks with\r\nrecommendations to help you further refine your policies. To learn more about policy validation, see IAM policy\r\nvalidation. To learn more about IAM Access Analyzer policy checks and actionable recommendations, see IAM\r\nAccess Analyzer policy validation.\r\nJSON policy document structure\r\nAs illustrated in the following figure, a JSON policy document includes these elements:\r\nOptional policy-wide information at the top of the document\r\nOne or more individual statements\r\nEach statement includes information about a single permission. If a policy includes multiple statements, AWS\r\napplies a logical OR across the statements when evaluating them. If multiple policies apply to a request, AWS\r\napplies a logical OR across all of those policies when evaluating them.\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 5 of 10\n\nThe information in a statement is contained within a series of elements.\r\nVersion – Specify the version of the policy language that you want to use. We recommend that you use the\r\nlatest 2012-10-17 version. For more information, see IAM JSON policy elements: Version\r\nStatement – Use this main policy element as a container for the following elements. You can include more\r\nthan one statement in a policy.\r\nSid (Optional) – Include an optional statement ID to differentiate between your statements.\r\nEffect – Use Allow or Deny to indicate whether the policy allows or denies access.\r\nPrincipal (Required in some circumstances) – If you create a resource-based policy, you must indicate the\r\naccount, user, role, or AWS STS federated user principal to which you would like to allow or deny access.\r\nIf you are creating an IAM permissions policy to attach to a user or role, you cannot include this element.\r\nThe principal is implied as that user or role.\r\nAction – Include a list of actions that the policy allows or denies.\r\nResource (Required in some circumstances) – If you create an IAM permissions policy, you must specify a\r\nlist of resources to which the actions apply. If you create a resource-based policy, it depends on the\r\nresource you're using as to whether this element is required or not.\r\nCondition (Optional) – Specify the circumstances under which the policy grants permission.\r\nTo learn about these and other more advanced policy elements, see IAM JSON policy element reference.\r\nMultiple statements and multiple policies\r\nIf you want to define more than one permission for an entity (user or role), you can use multiple statements in a\r\nsingle policy. You can also attach multiple policies. If you try to define multiple permissions in a single statement,\r\nyour policy might not grant the access that you expect. We recommend that you break up policies by resource\r\ntype.\r\nBecause of the limited size of policies, it might be necessary to use multiple policies for more complex\r\npermissions. It's also a good idea to create functional groupings of permissions in a separate customer managed\r\npolicy. For example, Create one policy for IAM user management, one for self-management, and another policy\r\nfor S3 bucket management. Regardless of the combination of multiple statements and multiple policies, AWS\r\nevaluates your policies the same way.\r\nFor example, the following policy has three statements, each of which defines a separate set of permissions within\r\na single account. The statements define the following:\r\nThe first statement, with an Sid (Statement ID) of FirstStatement , lets the user with the attached\r\npolicy change their own password. The Resource element in this statement is \" * \" (which means \"all\r\nresources\"). But in practice, the ChangePassword API operation (or equivalent change-password CLI\r\ncommand) affects only the password for the user who makes the request.\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 6 of 10\n\nThe second statement lets the user list all the Amazon S3 buckets in their AWS account. The Resource\r\nelement in this statement is \"*\" (which means \"all resources\"). But because policies don't grant access to\r\nresources in other accounts, the user can list only the buckets in their own AWS account.\r\nThe third statement lets the user list and retrieve any object that is in a bucket named amzn-s3-demo-bucket-confidential-data , but only when the user is authenticated with multi-factor authentication\r\n(MFA). The Condition element in the policy enforces the MFA authentication.\r\nWhen a policy statement contains a Condition element, the statement is only in effect when the\r\nCondition element evaluates to true. In this case, the Condition evaluates to true when the user is\r\nMFA-authenticated. If the user is not MFA-authenticated, this Condition evaluates to false. In that case,\r\nthe third statement in this policy does not apply and the user does not have access to the amzn-s3-demo-bucket-confidential-data bucket.\r\n{\r\n \"Version\":\"2012-10-17\",\r\n \"Statement\": [\r\n {\r\n \"Sid\": \"FirstStatement\",\r\n \"Effect\": \"Allow\",\r\n \"Action\": [\"iam:ChangePassword\"],\r\n \"Resource\": \"*\"\r\n },\r\n {\r\n \"Sid\": \"SecondStatement\",\r\n \"Effect\": \"Allow\",\r\n \"Action\": \"s3:ListAllMyBuckets\",\r\n \"Resource\": \"*\"\r\n },\r\n {\r\n \"Sid\": \"ThirdStatement\",\r\n \"Effect\": \"Allow\",\r\n \"Action\": [\r\n \"s3:List*\",\r\n \"s3:Get*\"\r\n ],\r\n \"Resource\": [\r\n \"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data\",\r\n \"arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*\"\r\n ],\r\n \"Condition\": {\"Bool\": {\"aws:MultiFactorAuthPresent\": \"true\"}}\r\n }\r\n ]\r\n}\r\nExamples of JSON policy syntax\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 7 of 10\n\nThe following identity-based policy allows the implied principal to list a single Amazon S3 bucket named amzn-s3-demo-bucket :\r\n{\r\n \"Version\":\"2012-10-17\",\r\n \"Statement\": {\r\n \"Effect\": \"Allow\",\r\n \"Action\": \"s3:ListBucket\",\r\n \"Resource\": \"arn:aws:s3:::amzn-s3-demo-bucket\"\r\n }\r\n}\r\nThe following resource-based policy can be attached to an Amazon S3 bucket. The policy allows members of a\r\nspecific AWS account to perform any Amazon S3 actions in the bucket named amzn-s3-demo-bucket . It allows\r\nany action that can be performed on a bucket or the objects within it. (Because the policy grants trust only to the\r\naccount, individual users in the account must still be granted permissions for the specified Amazon S3 actions.)\r\n{\r\n \"Version\":\"2012-10-17\",\r\n \"Statement\": [\r\n {\r\n \"Sid\": \"1\",\r\n \"Effect\": \"Allow\",\r\n \"Principal\": {\r\n \"AWS\": [\r\n \"arn:aws:iam:: 111122223333 :root\"\r\n ]\r\n },\r\n \"Action\": \"s3:*\",\r\n \"Resource\": [\r\n \"arn:aws:s3:::amzn-s3-demo-bucket\",\r\n \"arn:aws:s3:::amzn-s3-demo-bucket/*\"\r\n ]\r\n }\r\n ]\r\n}\r\nTo view example policies for common scenarios, see Example IAM identity-based policies.\r\nGrant least privilege\r\nWhen you create IAM policies, follow the standard security advice of granting least privilege, or granting only the\r\npermissions required to perform a task. Determine what users and roles need to do and then craft policies that\r\nallow them to perform only those tasks.\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 8 of 10\n\nStart with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure\r\nthan starting with permissions that are too lenient and then trying to tighten them later.\r\nAs an alternative to least privilege, you can use AWS managed policies or policies with wildcard * permissions\r\nto get started with policies. Consider the security risk of granting your principals more permissions than they need\r\nto do their job. Monitor those principals to learn which permissions they are using. Then write least privilege\r\npolicies.\r\nIAM provides several options to help you refine the permissions that you grant.\r\nUnderstand access level groupings – You can use access level groupings to understand the level of access\r\nthat a policy grants. Policy actions are classified as List , Read , Write , Permissions management , or\r\nTagging . For example, you can choose actions from the List and Read access levels to grant read-only access to your users. To learn how to use policy summaries to understand access level permissions,\r\nsee Access levels in policy summaries.\r\nValidate your policies – You can perform policy validation using IAM Access Analyzer when you create\r\nand edit JSON policies. We recommend that you review and validate all of your existing policies. IAM\r\nAccess Analyzer provides over 100 policy checks to validate your policies. It generates security warnings\r\nwhen a statement in your policy allows access we consider overly permissive. You can use the actionable\r\nrecommendations that are provided through the security warnings as you work toward granting least\r\nprivilege. To learn more about policy checks provided by IAM Access Analyzer, see IAM Access Analyzer\r\npolicy validation.\r\nGenerate a policy based on access activity – To help you refine the permissions that you grant, you can\r\ngenerate an IAM policy that is based on the access activity for an IAM entity (user or role). IAM Access\r\nAnalyzer reviews your AWS CloudTrail logs and generates a policy template that contains the permissions\r\nthat have been used by the entity in your specified time frame. You can use the template to create a\r\nmanaged policy with fine-grained permissions and then attach it to the IAM entity. That way, you grant\r\nonly the permissions that the user or role needs to interact with AWS resources for your specific use case.\r\nTo learn more, see IAM Access Analyzer policy generation.\r\nUse last accessed information – Another feature that can help with least privilege is last accessed\r\ninformation. View this information on the Access Advisor tab on the IAM console details page for an IAM\r\nuser, group, role, or policy. Last accessed information also includes information about the actions that were\r\nlast accessed for some services, such as Amazon EC2, IAM, Lambda, and Amazon S3. If you sign in using\r\nAWS Organizations management account credentials, you can view service last accessed information in the\r\nAWS Organizations section of the IAM console. You can also use the AWS CLI or AWS API to retrieve a\r\nreport for last accessed information for entities or policies in IAM or AWS Organizations. You can use this\r\ninformation to identify unnecessary permissions so that you can refine your IAM or AWS Organizations\r\npolicies to better adhere to the principle of least privilege. For more information, see Refine permissions in\r\nAWS using last accessed information.\r\nReview account events in AWS CloudTrail – To further reduce permissions, you can view your account's\r\nevents in AWS CloudTrail Event history. CloudTrail event logs include detailed event information that\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 9 of 10\n\nyou can use to reduce the policy's permissions. The logs include only the actions and resources that your\r\nIAM entities need. For more information, see Viewing CloudTrail Events in the CloudTrail Console in the\r\nAWS CloudTrail User Guide.\r\nFor more information, see the following policy topics for individual services, which provide examples of how to\r\nwrite policies for service-specific resources.\r\nUsing resource-based policies for DynamoDB in the Amazon DynamoDB Developer Guide\r\nBucket policies for Amazon S3 in the Amazon Simple Storage Service User Guide\r\nAccess Control List (ACL) overview in the Amazon Simple Storage Service User Guide\r\nSource: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html"
	],
	"report_names": [
		"access_policies.html"
	],
	"threat_actors": [
		{
			"id": "2864e40a-f233-4618-ac61-b03760a41cbb",
			"created_at": "2023-12-01T02:02:34.272108Z",
			"updated_at": "2026-04-10T02:00:04.97558Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "ETDA:WildCard",
			"tools": [
				"RustDown",
				"SysJoker"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "256a6a2d-e8a2-4497-b399-628a7fad4b3e",
			"created_at": "2023-11-30T02:00:07.299845Z",
			"updated_at": "2026-04-10T02:00:03.484788Z",
			"deleted_at": null,
			"main_name": "WildCard",
			"aliases": [],
			"source_name": "MISPGALAXY:WildCard",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434761,
	"ts_updated_at": 1775792121,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a84f65c0f6e969e52da623c045a1c2609f9fd210.pdf",
		"text": "https://archive.orkl.eu/a84f65c0f6e969e52da623c045a1c2609f9fd210.txt",
		"img": "https://archive.orkl.eu/a84f65c0f6e969e52da623c045a1c2609f9fd210.jpg"
	}
}