As I understand it, ATT&CK updates work in the way you describe them.
Arango queries make it hard to see the diff between changes (which I appreciate is what you asked), but let me try and get you a bit closer…
New objects
Simplest of all the changes. In v14 the sub-technique Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access T1548.005) was added.
The STIX object for this looks as follows;
{
"type": "bundle",
"id": "bundle--c00c7fdb-87c9-41e6-b345-9f1a0f2629c4",
"spec_version": "2.0",
"objects": [
{
"modified": "2023-10-03T17:38:56.602Z",
"name": "Temporary Elevated Cloud Access",
"description": "Adversaries may abuse permission configurations that allow them to gain temporarily elevated access to cloud resources. Many cloud environments allow administrators to grant user or service accounts permission to request just-in-time access to roles, impersonate other accounts, pass roles onto resources and services, or otherwise gain short-term access to a set of privileges that may be distinct from their own. \n\nJust-in-time access is a mechanism for granting additional roles to cloud accounts in a granular, temporary manner. This allows accounts to operate with only the permissions they need on a daily basis, and to request additional permissions as necessary. Sometimes just-in-time access requests are configured to require manual approval, while other times the desired permissions are automatically granted.(Citation: Google Cloud Just in Time Access 2023)(Citation: Azure Just in Time Access 2023)\n\nAccount impersonation allows user or service accounts to temporarily act with the permissions of another account. For example, in GCP users with the `iam.serviceAccountTokenCreator` role can create temporary access tokens or sign arbitrary payloads with the permissions of a service account.(Citation: Google Cloud Service Account Authentication Roles) In Exchange Online, the `ApplicationImpersonation` role allows a service account to use the permissions associated with specified user accounts.(Citation: Microsoft Impersonation and EWS in Exchange) \n\nMany cloud environments also include mechanisms for users to pass roles to resources that allow them to perform tasks and authenticate to other services. While the user that creates the resource does not directly assume the role they pass to it, they may still be able to take advantage of the role's access -- for example, by configuring the resource to perform certain actions with the permissions it has been granted. In AWS, users with the `PassRole` permission can allow a service they create to assume a given role, while in GCP, users with the `iam.serviceAccountUser` role can attach a service account to a resource.(Citation: AWS PassRole)(Citation: Google Cloud Service Account Authentication Roles)\n\nWhile users require specific role assignments in order to use any of these features, cloud administrators may misconfigure permissions. This could result in escalation paths that allow adversaries to gain access to resources beyond what was originally intended.(Citation: Rhino Google Cloud Privilege Escalation)(Citation: Rhino Security Labs AWS Privilege Escalation)\n\n**Note:** this technique is distinct from [Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003), which involves assigning permanent roles to accounts rather than abusing existing permissions structures to gain temporarily elevated access to resources. However, adversaries that compromise a sufficiently privileged account may grant another account they control [Additional Cloud Roles](https://attack.mitre.org/techniques/T1098/003) that would allow them to also abuse these features. This may also allow for greater stealth than would be had by directly using the highly privileged account, especially when logs do not clarify when role impersonation is taking place.(Citation: CrowdStrike StellarParticle January 2022)",
"kill_chain_phases": [
{
"kill_chain_name": "mitre-attack",
"phase_name": "privilege-escalation"
},
{
"kill_chain_name": "mitre-attack",
"phase_name": "defense-evasion"
}
],
"x_mitre_contributors": [
"Arad Inbar, Fidelis Security"
],
"x_mitre_deprecated": false,
"x_mitre_detection": "",
"x_mitre_domains": [
"enterprise-attack"
],
"x_mitre_is_subtechnique": true,
"x_mitre_platforms": [
"IaaS",
"Azure AD",
"Office 365"
],
"x_mitre_version": "1.0",
"x_mitre_data_sources": [
"User Account: User Account Modification"
],
"type": "attack-pattern",
"id": "attack-pattern--6fa224c7-5091-4595-bf15-3fc9fe2f2c7c",
"created": "2023-07-10T16:37:15.672Z",
"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"revoked": false,
"external_references": [
{
"source_name": "mitre-attack",
"url": "https://attack.mitre.org/techniques/T1548/005",
"external_id": "T1548.005"
},
{
"source_name": "AWS PassRole",
"description": "AWS. (n.d.). Granting a user permissions to pass a role to an AWS service. Retrieved July 10, 2023.",
"url": "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html"
},
{
"source_name": "CrowdStrike StellarParticle January 2022",
"description": "CrowdStrike. (2022, January 27). Early Bird Catches the Wormhole: Observations from the StellarParticle Campaign. Retrieved February 7, 2022.",
"url": "https://www.crowdstrike.com/blog/observations-from-the-stellarparticle-campaign/"
},
{
"source_name": "Google Cloud Just in Time Access 2023",
"description": "Google Cloud. (n.d.). Manage just-in-time privileged access to projects. Retrieved September 21, 2023.",
"url": "https://cloud.google.com/architecture/manage-just-in-time-privileged-access-to-project"
},
{
"source_name": "Google Cloud Service Account Authentication Roles",
"description": "Google Cloud. (n.d.). Roles for service account authentication. Retrieved July 10, 2023.",
"url": "https://cloud.google.com/iam/docs/service-account-permissions"
},
{
"source_name": "Microsoft Impersonation and EWS in Exchange",
"description": "Microsoft. (2022, September 13). Impersonation and EWS in Exchange. Retrieved July 10, 2023.",
"url": "https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/impersonation-and-ews-in-exchange"
},
{
"source_name": "Azure Just in Time Access 2023",
"description": "Microsoft. (2023, August 29). Configure and approve just-in-time access for Azure Managed Applications. Retrieved September 21, 2023.",
"url": "https://learn.microsoft.com/en-us/azure/azure-resource-manager/managed-applications/approve-just-in-time-access"
},
{
"source_name": "Rhino Security Labs AWS Privilege Escalation",
"description": "Spencer Gietzen. (n.d.). AWS IAM Privilege Escalation \u2013 Methods and Mitigation. Retrieved May 27, 2022.",
"url": "https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/"
},
{
"source_name": "Rhino Google Cloud Privilege Escalation",
"description": "Spencer Gietzen. (n.d.). Privilege Escalation in Google Cloud Platform \u2013 Part 1 (IAM). Retrieved September 21, 2023.",
"url": "https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/"
}
],
"object_marking_refs": [
"marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
],
"x_mitre_attack_spec_version": "3.2.0",
"x_mitre_modified_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5"
}
]
}
For new objects, the x_mitre_version property is always 1.0 (more on this in major / minor updates).
x_mitre_attack_spec_version relates to the version of the ATT&CK spec used (NOT the version of ATT&CK). Current and previous specs can be viewed here: attack-stix-data/USAGE.md at master · mitre-attack/attack-stix-data · GitHub
Don’t confuse x_mitre_attack_spec_version and spec_version. spec_version refers to the STIX version, and has nothing to do with ATT&CK.
A simple query to check for new / removed objects between versions (14 and 15.1 here)
LET ids_v14_0 = (
FOR doc IN mitre_attack_enterprise_vertex_collection
FILTER doc._stix2arango_note == "v14.0"
AND doc.type != "relationship"
RETURN doc.id
)
LET ids_v15_1 = (
FOR doc IN mitre_attack_enterprise_vertex_collection
FILTER doc._stix2arango_note == "v15.1"
AND doc.type != "relationship"
RETURN doc.id
)
LET removed_ids = MINUS(ids_v14_0, ids_v15_1)
LET added_ids = MINUS(ids_v15_1, ids_v14_0)
RETURN {
removed: removed_ids,
added: added_ids
}
[
{
"removed": [],
"added": [
"malware--d9765cbd-4c88-4805-ba98-4c6ccb56b864",
"malware--d79b1800-3b5d-4a4f-8863-8251eca793e2",
"malware--bd2ebee8-7c38-408a-871d-221012104222",
"malware--ae91fb8f-5031-4f57-9839-e3be3ed503f0",
"malware--a5818d36-e9b0-46da-842d-b727a5e36ea6",
"malware--9a097d18-d15f-4635-a4f1-189df7efdc40",
Deprecations
In v14 (Updates - Updates - October 2023 | MITRE ATT&CK®) the campaign Oldsmar Treatment Plant Intrusion (C0009) was deprecated from the ICS Matrix.
The object for C0009 is in the ICS v14 bundle (cti/ics-attack/ics-attack.json at ATT&CK-v14.0 · mitre/cti · GitHub)
{
"modified": "2023-09-20T22:40:13.147Z",
"name": "Oldsmar Treatment Plant Intrusion",
"description": "[Oldsmar Treatment Plant Intrusion](https://attack.mitre.org/campaigns/C0009) was a cyber incident involving a water treatment facility in Florida. During this incident, unidentified threat actors leveraged features of the system to access and modify setpoints for a specific chemical required in the treatment process. The incident was detected immediately and prevented before it could cause any harm to the public.(Citation: Pinellas County Sheriffs Office February 2021)(Citation: CISA AA21-042A Water Treatment Intrusion Feb 2021)(Citation: Dragos Oldsmar Feb 2021)",
"aliases": [
"Oldsmar Treatment Plant Intrusion"
],
"first_seen": "2021-02-01T05:00:00.000Z",
"last_seen": "2021-02-01T05:00:00.000Z",
"x_mitre_first_seen_citation": "(Citation: Pinellas County Sheriffs Office February 2021)",
"x_mitre_last_seen_citation": "(Citation: Pinellas County Sheriffs Office February 2021)",
"x_mitre_deprecated": true,
"x_mitre_version": "1.0",
"type": "campaign",
"id": "campaign--65281d3e-b03c-46b8-8cd8-716363ac3cb2",
"created": "2022-09-20T20:53:14.373Z",
"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"revoked": false,
"external_references": [
{
"source_name": "mitre-attack",
"url": "https://attack.mitre.org/campaigns/C0009",
"external_id": "C0009"
},
{
"source_name": "CISA AA21-042A Water Treatment Intrusion Feb 2021",
"description": "CISA. (2021, February 11). Compromise of U.S. Water Treatment Facility . Retrieved October 18, 2022.",
"url": "https://www.cisa.gov/uscert/ncas/alerts/aa21-042a"
},
{
"source_name": "Pinellas County Sheriffs Office February 2021",
"description": "Pinellas County Sheriffs Office 2021, February 8 Treatment Plant Intrusion Press Conference Retrieved. 2021/10/08 ",
"url": "https://www.youtube.com/watch?v=MkXDSOgLQ6M"
},
{
"source_name": "Dragos Oldsmar Feb 2021",
"description": "Serino, G., et al . (2021, February 8). Recommendations Following the Oldsmar Water Treatment Facility Cyber Attack. Retrieved October 21, 2022.",
"url": "https://www.dragos.com/blog/industry-news/recommendations-following-the-oldsmar-water-treatment-facility-cyber-attack/"
}
],
"object_marking_refs": [
"marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
],
"x_mitre_attack_spec_version": "3.1.0",
"x_mitre_modified_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"x_mitre_domains": [
"ics-attack"
]
}
You can see the property x_mitre_deprecated is true, representing the deprecation.
I am not really sure why MITRE don’t also change the STIX revoked property to true as well. This is due to the fact many tools understand this default STIX property natively (the same might not be true for x_mitre_deprecated).
Major updates
Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder (T1547.001) had a major version change between ATT&CK Enterprise v13 and v14.
Here’s what the object looks like in v13 (has ID attack-pattern--9efb1ea7-c37b-4595-9640-b7680cd84279)
{
"type": "bundle",
"id": "bundle--613eae34-f28f-4a81-a31f-8bd9eae27c3f",
"spec_version": "2.0",
"objects": [
{
"modified": "2023-03-30T21:01:52.183Z",
"name": "Registry Run Keys / Startup Folder",
"description": "Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the \"run keys\" in the Registry or startup folder will cause the program referenced to be executed when a user logs in.(Citation: Microsoft Run Key) These programs will be executed under the context of the user and will have the account's associated permissions level.\n\nPlacing a program within a startup folder will also cause that program to execute when a user logs in. There is a startup folder location for individual user accounts as well as a system-wide startup folder that will be checked regardless of which user account logs in. The startup folder path for the current user is <code>C:\\Users\\\\[Username]\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup</code>. The startup folder path for all users is <code>C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp</code>.\n\nThe following run keys are created by default on Windows systems:\n\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce</code>\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run</code>\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce</code>\n\nRun keys may exist under multiple hives.(Citation: Microsoft Wow6432Node 2018)(Citation: Malwarebytes Wow6432Node 2016) The <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx</code> is also available but is not created by default on Windows Vista and newer. Registry run key entries can reference programs directly or list them as a dependency.(Citation: Microsoft Run Key) For example, it is possible to load a DLL at logon using a \"Depend\" key with RunOnceEx: <code>reg add HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\0001\\Depend /v 1 /d \"C:\\temp\\evil[.]dll\"</code> (Citation: Oddvar Moe RunOnceEx Mar 2018)\n\nThe following Registry keys can be used to set startup folder items for persistence:\n\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders</code>\n* <code>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders</code>\n* <code>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders</code>\n\nThe following Registry keys can control automatic startup of services during boot:\n\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce</code>\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServices</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServices</code>\n\nUsing policy settings to specify startup programs creates corresponding values in either of two Registry keys:\n\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run</code>\n\nThe Winlogon key controls actions that occur when a user logs on to a computer running Windows 7. Most of these actions are under the control of the operating system, but you can also add custom actions here. The <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Userinit</code> and <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Shell</code> subkeys can automatically launch programs.\n\nPrograms listed in the load value of the registry key <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows</code> run when any user logs on.\n\nBy default, the multistring <code>BootExecute</code> value of the registry key <code>HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager</code> is set to <code>autocheck autochk *</code>. This value causes Windows, at startup, to check the file-system integrity of the hard disks if the system has been shut down abnormally. Adversaries can add other programs or processes to this registry value which will automatically launch at boot.\n\nAdversaries can use these configuration locations to execute malware, such as remote access tools, to maintain persistence through system reboots. Adversaries may also use [Masquerading](https://attack.mitre.org/techniques/T1036) to make the Registry entries look as if they are associated with legitimate programs.",
"kill_chain_phases": [
{
"kill_chain_name": "mitre-attack",
"phase_name": "persistence"
},
{
"kill_chain_name": "mitre-attack",
"phase_name": "privilege-escalation"
}
],
"x_mitre_attack_spec_version": "2.1.0",
"x_mitre_contributors": [
"Oddvar Moe, @oddvarmoe",
"Dray Agha, @Purp1eW0lf, Huntress Labs"
],
"x_mitre_deprecated": false,
"x_mitre_detection": "Monitor Registry for changes to run keys that do not correlate with known software, patch cycles, etc. Monitor the start folder for additions or changes. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including listing the run keys' Registry locations and startup folders. (Citation: TechNet Autoruns) Suspicious program execution as startup programs may show up as outlier processes that have not been seen before when compared against historical data.\n\nChanges to these locations typically happen under normal conditions when legitimate software is installed. To increase confidence of malicious activity, data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities, such as network connections made for Command and Control, learning details about the environment through Discovery, and Lateral Movement.",
"x_mitre_domains": [
"enterprise-attack"
],
"x_mitre_is_subtechnique": true,
"x_mitre_modified_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"x_mitre_platforms": [
"Windows"
],
"x_mitre_version": "1.2",
"x_mitre_data_sources": [
"Windows Registry: Windows Registry Key Creation",
"Windows Registry: Windows Registry Key Modification",
"Command: Command Execution",
"Process: Process Creation",
"File: File Modification"
],
"x_mitre_permissions_required": [
"Administrator",
"User"
],
"type": "attack-pattern",
"id": "attack-pattern--9efb1ea7-c37b-4595-9640-b7680cd84279",
"created": "2020-01-23T22:02:48.566Z",
"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"revoked": false,
"external_references": [
{
"source_name": "mitre-attack",
"url": "https://attack.mitre.org/techniques/T1547/001",
"external_id": "T1547.001"
},
{
"source_name": "Malwarebytes Wow6432Node 2016",
"description": "Arntz, P. (2016, March 30). Hiding in Plain Sight. Retrieved August 3, 2020.",
"url": "https://blog.malwarebytes.com/cybercrime/2013/10/hiding-in-plain-sight/"
},
{
"source_name": "Microsoft Wow6432Node 2018",
"description": "Microsoft. (2018, May 31). 32-bit and 64-bit Application Data in the Registry. Retrieved August 3, 2020.",
"url": "https://docs.microsoft.com/en-us/windows/win32/sysinfo/32-bit-and-64-bit-application-data-in-the-registry"
},
{
"source_name": "Microsoft Run Key",
"description": "Microsoft. (n.d.). Run and RunOnce Registry Keys. Retrieved November 12, 2014.",
"url": "http://msdn.microsoft.com/en-us/library/aa376977"
},
{
"source_name": "Oddvar Moe RunOnceEx Mar 2018",
"description": "Moe, O. (2018, March 21). Persistence using RunOnceEx - Hidden from Autoruns.exe. Retrieved June 29, 2018.",
"url": "https://oddvar.moe/2018/03/21/persistence-using-runonceex-hidden-from-autoruns-exe/"
},
{
"source_name": "TechNet Autoruns",
"description": "Russinovich, M. (2016, January 4). Autoruns for Windows v13.51. Retrieved June 6, 2016.",
"url": "https://technet.microsoft.com/en-us/sysinternals/bb963902"
}
],
"object_marking_refs": [
"marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
]
}
]
}
And in v14 (has ID attack-pattern--9efb1ea7-c37b-4595-9640-b7680cd84279)
{
"modified": "2023-10-16T09:08:22.319Z",
"name": "Registry Run Keys / Startup Folder",
"description": "Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the \"run keys\" in the Registry or startup folder will cause the program referenced to be executed when a user logs in.(Citation: Microsoft Run Key) These programs will be executed under the context of the user and will have the account's associated permissions level.\n\nThe following run keys are created by default on Windows systems:\n\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce</code>\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run</code>\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce</code>\n\nRun keys may exist under multiple hives.(Citation: Microsoft Wow6432Node 2018)(Citation: Malwarebytes Wow6432Node 2016) The <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx</code> is also available but is not created by default on Windows Vista and newer. Registry run key entries can reference programs directly or list them as a dependency.(Citation: Microsoft Run Key) For example, it is possible to load a DLL at logon using a \"Depend\" key with RunOnceEx: <code>reg add HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\0001\\Depend /v 1 /d \"C:\\temp\\evil[.]dll\"</code> (Citation: Oddvar Moe RunOnceEx Mar 2018)\n\nPlacing a program within a startup folder will also cause that program to execute when a user logs in. There is a startup folder location for individual user accounts as well as a system-wide startup folder that will be checked regardless of which user account logs in. The startup folder path for the current user is <code>C:\\Users\\\\[Username]\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup</code>. The startup folder path for all users is <code>C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp</code>.\n\nThe following Registry keys can be used to set startup folder items for persistence:\n\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders</code>\n* <code>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders</code>\n* <code>HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders</code>\n\nThe following Registry keys can control automatic startup of services during boot:\n\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce</code>\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServices</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServices</code>\n\nUsing policy settings to specify startup programs creates corresponding values in either of two Registry keys:\n\n* <code>HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run</code>\n* <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run</code>\n\nPrograms listed in the load value of the registry key <code>HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Windows</code> run automatically for the currently logged-on user.\n\nBy default, the multistring <code>BootExecute</code> value of the registry key <code>HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager</code> is set to <code>autocheck autochk *</code>. This value causes Windows, at startup, to check the file-system integrity of the hard disks if the system has been shut down abnormally. Adversaries can add other programs or processes to this registry value which will automatically launch at boot.\n\nAdversaries can use these configuration locations to execute malware, such as remote access tools, to maintain persistence through system reboots. Adversaries may also use [Masquerading](https://attack.mitre.org/techniques/T1036) to make the Registry entries look as if they are associated with legitimate programs.",
"kill_chain_phases": [
{
"kill_chain_name": "mitre-attack",
"phase_name": "persistence"
},
{
"kill_chain_name": "mitre-attack",
"phase_name": "privilege-escalation"
}
],
"x_mitre_contributors": [
"Oddvar Moe, @oddvarmoe",
"Dray Agha, @Purp1eW0lf, Huntress Labs",
"Harun Küßner"
],
"x_mitre_deprecated": false,
"x_mitre_detection": "Monitor Registry for changes to run keys that do not correlate with known software, patch cycles, etc. Monitor the start folder for additions or changes. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including listing the run keys' Registry locations and startup folders. (Citation: TechNet Autoruns) Suspicious program execution as startup programs may show up as outlier processes that have not been seen before when compared against historical data.\n\nChanges to these locations typically happen under normal conditions when legitimate software is installed. To increase confidence of malicious activity, data and events should not be viewed in isolation, but as part of a chain of behavior that could lead to other activities, such as network connections made for Command and Control, learning details about the environment through Discovery, and Lateral Movement.",
"x_mitre_domains": [
"enterprise-attack"
],
"x_mitre_is_subtechnique": true,
"x_mitre_platforms": [
"Windows"
],
"x_mitre_version": "2.0",
"x_mitre_data_sources": [
"Command: Command Execution",
"File: File Modification",
"Process: Process Creation",
"Windows Registry: Windows Registry Key Creation",
"Windows Registry: Windows Registry Key Modification"
],
"x_mitre_permissions_required": [
"Administrator",
"User"
],
"type": "attack-pattern",
"id": "attack-pattern--9efb1ea7-c37b-4595-9640-b7680cd84279",
"created": "2020-01-23T22:02:48.566Z",
"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"revoked": false,
"external_references": [
{
"source_name": "mitre-attack",
"url": "https://attack.mitre.org/techniques/T1547/001",
"external_id": "T1547.001"
},
{
"source_name": "Malwarebytes Wow6432Node 2016",
"description": "Arntz, P. (2016, March 30). Hiding in Plain Sight. Retrieved August 3, 2020.",
"url": "https://blog.malwarebytes.com/cybercrime/2013/10/hiding-in-plain-sight/"
},
{
"source_name": "Microsoft Wow6432Node 2018",
"description": "Microsoft. (2018, May 31). 32-bit and 64-bit Application Data in the Registry. Retrieved August 3, 2020.",
"url": "https://docs.microsoft.com/en-us/windows/win32/sysinfo/32-bit-and-64-bit-application-data-in-the-registry"
},
{
"source_name": "Microsoft Run Key",
"description": "Microsoft. (n.d.). Run and RunOnce Registry Keys. Retrieved November 12, 2014.",
"url": "http://msdn.microsoft.com/en-us/library/aa376977"
},
{
"source_name": "Oddvar Moe RunOnceEx Mar 2018",
"description": "Moe, O. (2018, March 21). Persistence using RunOnceEx - Hidden from Autoruns.exe. Retrieved June 29, 2018.",
"url": "https://oddvar.moe/2018/03/21/persistence-using-runonceex-hidden-from-autoruns-exe/"
},
{
"source_name": "TechNet Autoruns",
"description": "Russinovich, M. (2016, January 4). Autoruns for Windows v13.51. Retrieved June 6, 2016.",
"url": "https://technet.microsoft.com/en-us/sysinternals/bb963902"
}
],
"object_marking_refs": [
"marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
],
"x_mitre_attack_spec_version": "3.2.0",
"x_mitre_modified_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5"
}
See how in v13 the x_mitre_version is 1.2.
In v14 x_mitre_version is 2.0.
You can see the major version is bumped between the updates, allowing us to see there has been a major change between versions.
What actually constitutes a major/minor update is decided upon by the MITRE ATT&CK team. I can’t actually find any official explanations on this.
As I mentioned, in v13 the x_mitre_version is 1.2 for this object. I noted for new object x_mitre_version starts at 1.0. Therefore this object has previously gone through 2 minor updates.
Here’s a real example of a minor update…
Minor updates
In v14 Abuse Elevation Control Mechanism (T1548) went from v1.1 to v1.2.
Here’s what it looked like in v13
{
"type": "bundle",
"id": "bundle--4ed5669c-d767-451d-97ef-6ed824ee93b0",
"spec_version": "2.0",
"objects": [
{
"modified": "2023-04-21T12:35:07.744Z",
"name": "Abuse Elevation Control Mechanism",
"description": "Adversaries may circumvent mechanisms designed to control elevate privileges to gain higher-level permissions. Most modern systems contain native elevation control mechanisms that are intended to limit privileges that a user can perform on a machine. Authorization has to be granted to specific users in order to perform tasks that can be considered of higher risk. An adversary can perform several methods to take advantage of built-in control mechanisms in order to escalate privileges on a system.",
"kill_chain_phases": [
{
"kill_chain_name": "mitre-attack",
"phase_name": "privilege-escalation"
},
{
"kill_chain_name": "mitre-attack",
"phase_name": "defense-evasion"
}
],
"x_mitre_deprecated": false,
"x_mitre_detection": "Monitor the file system for files that have the setuid or setgid bits set. Also look for any process API calls for behavior that may be indicative of [Process Injection](https://attack.mitre.org/techniques/T1055) and unusual loaded DLLs through [DLL Search Order Hijacking](https://attack.mitre.org/techniques/T1574/001), which indicate attempts to gain access to higher privileged processes. On Linux, auditd can alert every time a user's actual ID and effective ID are different (this is what happens when you sudo).\n\nConsider monitoring for <code>/usr/libexec/security_authtrampoline</code> executions which may indicate that AuthorizationExecuteWithPrivileges is being executed. MacOS system logs may also indicate when AuthorizationExecuteWithPrivileges is being called. Monitoring OS API callbacks for the execution can also be a way to detect this behavior but requires specialized security tooling.\n\nOn Linux, auditd can alert every time a user's actual ID and effective ID are different (this is what happens when you sudo). This technique is abusing normal functionality in macOS and Linux systems, but sudo has the ability to log all input and output based on the <code>LOG_INPUT</code> and <code>LOG_OUTPUT</code> directives in the <code>/etc/sudoers</code> file.\n\nThere are many ways to perform UAC bypasses when a user is in the local administrator group on a system, so it may be difficult to target detection on all variations. Efforts should likely be placed on mitigation and collecting enough information on process launches and actions that could be performed before and after a UAC bypass is performed. Some UAC bypass methods rely on modifying specific, user-accessible Registry settings. Analysts should monitor Registry settings for unauthorized changes.",
"x_mitre_domains": [
"enterprise-attack"
],
"x_mitre_is_subtechnique": false,
"x_mitre_platforms": [
"Linux",
"macOS",
"Windows"
],
"x_mitre_version": "1.1",
"x_mitre_data_sources": [
"Process: Process Creation",
"File: File Metadata",
"Process: OS API Execution",
"File: File Modification",
"Windows Registry: Windows Registry Key Modification",
"Process: Process Metadata",
"Command: Command Execution"
],
"x_mitre_permissions_required": [
"Administrator",
"User"
],
"type": "attack-pattern",
"id": "attack-pattern--67720091-eee3-4d2d-ae16-8264567f6f5b",
"created": "2020-01-30T13:58:14.373Z",
"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"revoked": false,
"external_references": [
{
"source_name": "mitre-attack",
"url": "https://attack.mitre.org/techniques/T1548",
"external_id": "T1548"
}
],
"object_marking_refs": [
"marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
],
"x_mitre_attack_spec_version": "3.1.0",
"x_mitre_modified_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5"
}
]
}
See x_mitre_version is 1.1
And v14
{
"type": "bundle",
"id": "bundle--7504b0ec-8e08-49a9-bbff-6b4b3b390332",
"spec_version": "2.0",
"objects": [
{
"modified": "2023-10-02T00:47:11.369Z",
"name": "Abuse Elevation Control Mechanism",
"description": "Adversaries may circumvent mechanisms designed to control elevate privileges to gain higher-level permissions. Most modern systems contain native elevation control mechanisms that are intended to limit privileges that a user can perform on a machine. Authorization has to be granted to specific users in order to perform tasks that can be considered of higher risk. An adversary can perform several methods to take advantage of built-in control mechanisms in order to escalate privileges on a system.",
"kill_chain_phases": [
{
"kill_chain_name": "mitre-attack",
"phase_name": "privilege-escalation"
},
{
"kill_chain_name": "mitre-attack",
"phase_name": "defense-evasion"
}
],
"x_mitre_deprecated": false,
"x_mitre_detection": "Monitor the file system for files that have the setuid or setgid bits set. Also look for any process API calls for behavior that may be indicative of [Process Injection](https://attack.mitre.org/techniques/T1055) and unusual loaded DLLs through [DLL Search Order Hijacking](https://attack.mitre.org/techniques/T1574/001), which indicate attempts to gain access to higher privileged processes. On Linux, auditd can alert every time a user's actual ID and effective ID are different (this is what happens when you sudo).\n\nConsider monitoring for <code>/usr/libexec/security_authtrampoline</code> executions which may indicate that AuthorizationExecuteWithPrivileges is being executed. MacOS system logs may also indicate when AuthorizationExecuteWithPrivileges is being called. Monitoring OS API callbacks for the execution can also be a way to detect this behavior but requires specialized security tooling.\n\nOn Linux, auditd can alert every time a user's actual ID and effective ID are different (this is what happens when you sudo). This technique is abusing normal functionality in macOS and Linux systems, but sudo has the ability to log all input and output based on the <code>LOG_INPUT</code> and <code>LOG_OUTPUT</code> directives in the <code>/etc/sudoers</code> file.\n\nThere are many ways to perform UAC bypasses when a user is in the local administrator group on a system, so it may be difficult to target detection on all variations. Efforts should likely be placed on mitigation and collecting enough information on process launches and actions that could be performed before and after a UAC bypass is performed. Some UAC bypass methods rely on modifying specific, user-accessible Registry settings. Analysts should monitor Registry settings for unauthorized changes.",
"x_mitre_domains": [
"enterprise-attack"
],
"x_mitre_is_subtechnique": false,
"x_mitre_platforms": [
"Linux",
"macOS",
"Windows",
"Office 365",
"IaaS",
"Google Workspace",
"Azure AD"
],
"x_mitre_version": "1.2",
"x_mitre_data_sources": [
"Process: Process Creation",
"User Account: User Account Modification",
"Command: Command Execution",
"Process: OS API Execution",
"File: File Modification",
"Process: Process Metadata",
"File: File Metadata",
"Windows Registry: Windows Registry Key Modification"
],
"x_mitre_permissions_required": [
"Administrator",
"User"
],
"type": "attack-pattern",
"id": "attack-pattern--67720091-eee3-4d2d-ae16-8264567f6f5b",
"created": "2020-01-30T13:58:14.373Z",
"created_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5",
"revoked": false,
"external_references": [
{
"source_name": "mitre-attack",
"url": "https://attack.mitre.org/techniques/T1548",
"external_id": "T1548"
}
],
"object_marking_refs": [
"marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
],
"x_mitre_attack_spec_version": "3.2.0",
"x_mitre_modified_by_ref": "identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5"
}
]
}
See x_mitre_version is 1.2
Creating ArangoDB queries
(I used stix2arango to import the objects for these searches)
Because of the STIX object ids are not always persistent in relation to ATT&CK IDs (e.g. b/c of major update) you need to use the ATT&CK ID to perform a diff on a specific object, e.g.
FOR doc IN mitre_attack_enterprise_vertex_collection
FILTER doc._stix2arango_note != "automatically imported on collection creation"
AND doc.type == "attack-pattern"
AND doc.x_mitre_is_subtechnique == false
FOR extRef IN doc.external_references
FILTER extRef.external_id == "T1548"
AND extRef.source_name == "mitre-attack"
LET keys = ATTRIBUTES(doc)
LET filteredKeys = keys[* FILTER !STARTS_WITH(CURRENT, "_")]
RETURN KEEP(doc, filteredKeys)
At the time of writing returns 17 results
To determine when changes happen
FOR doc IN mitre_attack_enterprise_vertex_collection
FILTER doc._stix2arango_note != "automatically imported on collection creation"
AND doc.type == "attack-pattern"
AND doc.x_mitre_is_subtechnique == false
FOR extRef IN doc.external_references
FILTER extRef.external_id == "T1548"
AND extRef.source_name == "mitre-attack"
COLLECT modified = doc.modified INTO grouped
RETURN {
modified,
notes: UNIQUE(grouped[*].doc._stix2arango_note)
}
[
{
"modified": "2020-06-25T19:57:54.923Z",
"notes": [
"v7.0",
"v7.1",
"v7.2"
]
},
{
"modified": "2020-07-22T21:36:52.825Z",
"notes": [
"v8.0",
"v8.1",
"v8.2"
]
},
{
"modified": "2021-04-29T14:49:39.188Z",
"notes": [
"v9.0",
"v10.0",
"v10.1"
]
},
In this case T1548 was introduced in ATT&CK 7.0, was changed in v8.0, and then v9.0 (i’ve omitted the other changes for brevity here).