voyagar/mitre_cit_v14 huggingface dataset:
T1578: Modify Cloud Compute Infrastructure
Tactics: Defense Evasion
Platforms: IaaS

An adversary may attempt to modify a cloud account's compute service infrastructure to evade defenses. A modification to the compute service infrastructure can include the creation, deletion, or modification of one or more components such as compute instances, virtual machines, and snapshots. Permissions gained from the modification of infrastructure components may bypass restrictions that prevent access to existing infrastructure. Modifying infrastructure components may also allow an adversary to evade detection and remove evidence of their presence.

Detection: Establish centralized logging for the activity of cloud compute infrastructure components. Monitor for suspicious sequences of events, such as the creation of multiple snapshots within a short period of time or the mount of a snapshot to a new instance by a new or unexpected user. To reduce false positives, valid change management procedures could introduce a known identifier that is logged with the change (e.g., tag or header) if supported by the cloud provider, to help distinguish valid, expected actions from malicious ones.
Data sources: Cloud Service: Cloud Service Metadata, Instance: Instance Creation, Instance: Instance Deletion, Instance: Instance Metadata, Instance: Instance Modification, Instance: Instance Start, Instance: Instance Stop, Snapshot: Snapshot Creation, Snapshot: Snapshot Deletion, Snapshot: Snapshot Metadata, Snapshot: Snapshot Modification, Volume: Volume Creation, Volume: Volume Deletion, Volume: Volume Metadata, Volume: Volume Modification
T1578.002: Modify Cloud Compute Infrastructure: Create Cloud Instance
Tactics: Defense Evasion
Platforms: IaaS
Sub-technique of: T1578

An adversary may create a new instance or virtual machine (VM) within the compute service of a cloud account to evade defenses. Creating a new instance may allow an adversary to bypass firewall rules and permissions that exist on instances currently residing within an account. An adversary may Create Snapshot of one or more volumes in an account, create a new instance, mount the snapshots, and then apply a less restrictive security policy to collect Data from Local System or for Remote Data Staging. Creating a new instance may also allow an adversary to carry out malicious activity within an environment without affecting the execution of current running instances.

Detection: The creation of a new instance or VM is a common part of operations within many cloud environments. Events should then not be viewed in isolation, but as part of a chain of behavior that could lead to other activities. For example, the creation of an instance by a new user account or the unexpected creation of one or more snapshots followed by the creation of an instance may indicate suspicious activity. In AWS, CloudTrail logs capture the creation of an instance in the RunInstances event, and in Azure the creation of a VM may be captured in Azure activity logs. Google's Admin Activity audit logs within their Cloud Audit logs can be used to detect the usage of gcloud compute instances create to create a VM.
Data sources: Instance: Instance Creation, Instance: Instance Metadata
T1578.001: Modify Cloud Compute Infrastructure: Create Snapshot
Tactics: Defense Evasion
Platforms: IaaS
Sub-technique of: T1578

An adversary may create a snapshot or data backup within a cloud account to evade defenses. A snapshot is a point-in-time copy of an existing cloud compute component such as a virtual machine (VM), virtual hard drive, or volume. An adversary may leverage permissions to create a snapshot in order to bypass restrictions that prevent access to existing compute service infrastructure, unlike in Revert Cloud Instance where an adversary may revert to a snapshot to evade detection and remove evidence of their presence. An adversary may Create Cloud Instance, mount one or more created snapshots to that instance, and then apply a policy that allows the adversary access to the created instance, such as a firewall policy that allows them inbound and outbound SSH access.

Detection: The creation of a snapshot is a common part of operations within many cloud environments. Events should then not be viewed in isolation, but as part of a chain of behavior that could lead to other activities such as the creation of one or more snapshots and the restoration of these snapshots by a new user account. In AWS, CloudTrail logs capture the creation of snapshots and all API calls for AWS Backup as events. Using the information collected by CloudTrail, you can determine the request that was made, the IP address from which the request was made, which user made the request, when it was made, and additional details.. In Azure, the creation of a snapshot may be captured in Azure activity logs. Backup restoration events can also be detected through Azure Monitor Log Data by creating a custom alert for completed restore jobs. Google's Admin Activity audit logs within their Cloud Audit logs can be used to detect the usage of the gcloud compute instances create command to create a new VM disk from a snapshot. It is also possible to detect the usage of the GCP API with the "sourceSnapshot": parameter pointed to "global/snapshots/[BOOTNAME].
Data sources: Snapshot: Snapshot Creation, Snapshot: Snapshot Metadata
T1578.003: Modify Cloud Compute Infrastructure: Delete Cloud Instance
Tactics: Defense Evasion
Platforms: IaaS
Sub-technique of: T1578

An adversary may delete a cloud instance after they have performed malicious activities in an attempt to evade detection and remove evidence of their presence. Deleting an instance or virtual machine can remove valuable forensic artifacts and other evidence of suspicious behavior if the instance is not recoverable. An adversary may also Create Cloud Instance and later terminate the instance after achieving their objectives.

Detection: The deletion of a new instance or virtual machine is a common part of operations within many cloud environments. Events should then not be viewed in isolation, but as part of a chain of behavior that could lead to other activities. For example, detecting a sequence of events such as the creation of an instance, mounting of a snapshot to that instance, and deletion of that instance by a new user account may indicate suspicious activity. In AWS, CloudTrail logs capture the deletion of an instance in the TerminateInstances event, and in Azure the deletion of a VM may be captured in Azure activity logs. Google's Admin Activity audit logs within their Cloud Audit logs can be used to detect the usage of gcloud compute instances delete to delete a VM.
Data sources: Instance: Instance Deletion, Instance: Instance Metadata
T1578.005: Modify Cloud Compute Infrastructure: Modify Cloud Compute Configurations
Tactics: Defense Evasion
Platforms: IaaS
Sub-technique of: T1578

Adversaries may modify settings that directly affect the size, locations, and resources available to cloud compute infrastructure in order to evade defenses. These settings may include service quotas, subscription associations, tenant-wide policies, or other configurations that impact available compute. Such modifications may allow adversaries to abuse the victim’s compute resources to achieve their goals, potentially without affecting the execution of running instances and/or revealing their activities to the victim. For example, cloud providers often limit customer usage of compute resources via quotas. Customers may request adjustments to these quotas to support increased computing needs, though these adjustments may require approval from the cloud provider. Adversaries who compromise a cloud environment may similarly request quota adjustments in order to support their activities, such as enabling additional Resource Hijacking without raising suspicion by using up a victim’s entire quota. Adversaries may also increase allowed resource usage by modifying any tenant-wide policies that limit the sizes of deployed virtual machines. Adversaries may also modify settings that affect where cloud resources can be deployed, such as enabling Unused/Unsupported Cloud Regions. In Azure environments, an adversary who has gained access to a Global Administrator account may create new subscriptions in which to deploy resources, or engage in subscription hijacking by transferring an existing pay-as-you-go subscription from a victim tenant to an adversary-controlled tenant. This will allow the adversary to use the victim’s compute resources without generating logs on the victim tenant.

Detection: No detection description provided.
Data sources: Cloud Service: Cloud Service Modification
T1578.004: Modify Cloud Compute Infrastructure: Revert Cloud Instance
Tactics: Defense Evasion
Platforms: IaaS
Sub-technique of: T1578

An adversary may revert changes made to a cloud instance after they have performed malicious activities in attempt to evade detection and remove evidence of their presence. In highly virtualized environments, such as cloud-based infrastructure, this may be accomplished by restoring virtual machine (VM) or data storage snapshots through the cloud management dashboard or cloud APIs. Another variation of this technique is to utilize temporary storage attached to the compute instance. Most cloud providers provide various types of storage including persistent, local, and/or ephemeral, with the ephemeral types often reset upon stop/restart of the VM.

Detection: Establish centralized logging of instance activity, which can be used to monitor and review system events even after reverting to a snapshot, rolling back changes, or changing persistence/type of storage. Monitor specifically for events related to snapshots and rollbacks and VM configuration changes, that are occurring outside of normal activity. To reduce false positives, valid change management procedures could introduce a known identifier that is logged with the change (e.g., tag or header) if supported by the cloud provider, to help distinguish valid, expected actions from malicious ones.
Data sources: Instance: Instance Metadata, Instance: Instance Modification, Instance: Instance Start, Instance: Instance Stop
T1535: Unused/Unsupported Cloud Regions
Tactics: Defense Evasion
Platforms: IaaS

Adversaries may create cloud instances in unused geographic service regions in order to evade detection. Access is usually obtained through compromising accounts used to manage cloud infrastructure. Cloud service providers often provide infrastructure throughout the world in order to improve performance, provide redundancy, and allow customers to meet compliance requirements. Oftentimes, a customer will only use a subset of the available regions and may not actively monitor other regions. If an adversary creates resources in an unused region, they may be able to operate undetected. A variation on this behavior takes advantage of differences in functionality across cloud regions. An adversary could utilize regions which do not support advanced detection services in order to avoid detection of their activity. An example of adversary use of unused AWS regions is to mine cryptocurrency through Resource Hijacking, which can cost organizations substantial amounts of money over time depending on the processing power used.

Detection: Monitor system logs to review activities occurring across all cloud environments and regions. Configure alerting to notify of activity in normally unused regions or if the number of instances active in a region goes above a certain threshold.
Data sources: Instance: Instance Creation, Instance: Instance Metadata
T1550: Use Alternate Authentication Material
Tactics: Defense Evasion, Lateral Movement
Platforms: Containers, Google Workspace, IaaS, Office 365, SaaS, Windows
Defenses bypassed: System Access Controls

Adversaries may use alternate authentication material, such as password hashes, Kerberos tickets, and application access tokens, in order to move laterally within an environment and bypass normal system access controls. Authentication processes generally require a valid identity (e.g., username) along with one or more authentication factors (e.g., password, pin, physical smart card, token generator, etc.). Alternate authentication material is legitimately generated by systems after a user or application successfully authenticates by providing a valid identity and the required authentication factor(s). Alternate authentication material may also be generated during the identity creation process. Caching alternate authentication material allows the system to verify an identity has successfully authenticated without asking the user to reenter authentication factor(s). Because the alternate authentication must be maintained by the system—either in memory or on disk—it may be at risk of being stolen through Credential Access techniques. By stealing alternate authentication material, adversaries are able to bypass system access controls and authenticate to systems without knowing the plaintext password or any additional authentication factors.

Detection: Configure robust, consistent account activity audit policies across the enterprise and with externally accessible services. Look for suspicious account behavior across systems that share accounts, either user, admin, or service accounts. Examples: one account logged into multiple systems simultaneously; multiple accounts logged into the same machine simultaneously; accounts logged in at odd times or outside of business hours. Activity may be from interactive login sessions or process ownership from accounts being used to execute binaries on a remote system as a particular account. Correlate other security systems with login information (e.g., a user has an active login session but has not entered the building or does not have VPN access).
Data sources: Active Directory: Active Directory Credential Request, Application Log: Application Log Content, Logon Session: Logon Session Creation, User Account: User Account Authentication, Web Credential: Web Credential Usage
T1550.004: Use Alternate Authentication Material: Web Session Cookie
Tactics: Defense Evasion, Lateral Movement
Platforms: Google Workspace, IaaS, Office 365, SaaS
Sub-technique of: T1550
Defenses bypassed: System Access Controls

Adversaries can use stolen session cookies to authenticate to web applications and services. This technique bypasses some multi-factor authentication protocols since the session is already authenticated. Authentication cookies are commonly used in web applications, including cloud-based services, after a user has authenticated to the service so credentials are not passed and re-authentication does not need to occur as frequently. Cookies are often valid for an extended period of time, even if the web application is not actively used. After the cookie is obtained through Steal Web Session Cookie or Web Cookies, the adversary may then import the cookie into a browser they control and is then able to use the site or application as the user for as long as the session cookie is active. Once logged into the site, an adversary can access sensitive information, read email, or perform actions that the victim account has permissions to perform. There have been examples of malware targeting session cookies to bypass multi-factor authentication systems.

Detection: Monitor for anomalous access of websites and cloud-based applications by the same user in different locations or by different systems that do not match expected configurations.
Data sources: Application Log: Application Log Content, Web Credential: Web Credential Usage
T1110: Brute Force
Tactics: Credential Access
Platforms: Azure AD, Containers, Google Workspace, IaaS, Linux, Network, Office 365, SaaS, Windows, macOS

Adversaries may use brute force techniques to gain access to accounts when passwords are unknown or when password hashes are obtained. Without knowledge of the password for an account or set of accounts, an adversary may systematically guess the password using a repetitive or iterative mechanism. Brute forcing passwords can take place via interaction with a service that will check the validity of those credentials or offline against previously acquired credential data, such as password hashes. Brute forcing credentials may take place at various points during a breach. For example, adversaries may attempt to brute force access to Valid Accounts within a victim environment leveraging knowledge gathered from other post-compromise behaviors such as OS Credential Dumping, Account Discovery, or Password Policy Discovery. Adversaries may also combine brute forcing activity with behaviors such as External Remote Services as part of Initial Access.

Detection: Monitor authentication logs for system and application login failures of Valid Accounts. If authentication failures are high, then there may be a brute force attempt to gain access to a system using legitimate credentials. Also monitor for many failed authentication attempts across various accounts that may result from password spraying attempts. It is difficult to detect when hashes are cracked, since this is generally done outside the scope of the target network.
Data sources: Application Log: Application Log Content, Command: Command Execution, User Account: User Account Authentication
T1110.004: Brute Force: Credential Stuffing
Tactics: Credential Access
Platforms: Azure AD, Containers, Google Workspace, IaaS, Linux, Office 365, SaaS, Windows, macOS
Sub-technique of: T1110

Adversaries may use credentials obtained from breach dumps of unrelated accounts to gain access to target accounts through credential overlap. Occasionally, large numbers of username and password pairs are dumped online when a website or service is compromised and the user account credentials accessed. The information may be useful to an adversary attempting to compromise accounts by taking advantage of the tendency for users to use the same passwords across personal and business accounts. Credential stuffing is a risky option because it could cause numerous authentication failures and account lockouts, depending on the organization's login failure policies. Typically, management services over commonly used ports are used when stuffing credentials. Commonly targeted services include the following:  SSH (22/TCP)  Telnet (23/TCP)  FTP (21/TCP)  NetBIOS / SMB / Samba (139/TCP & 445/TCP)  LDAP (389/TCP)  Kerberos (88/TCP)  RDP / Terminal Services (3389/TCP)  HTTP/HTTP Management Services (80/TCP & 443/TCP)  MSSQL (1433/TCP)  Oracle (1521/TCP)  MySQL (3306/TCP)  VNC (5900/TCP) In addition to management services, adversaries may "target single sign-on (SSO) and cloud-based applications utilizing federated authentication protocols," as well as externally facing email applications, such as Office 365.

Detection: Monitor authentication logs for system and application login failures of Valid Accounts. If authentication failures are high, then there may be a brute force attempt to gain access to a system using legitimate credentials.
Data sources: Application Log: Application Log Content, User Account: User Account Authentication
T1110.002: Brute Force: Password Cracking
Tactics: Credential Access
Platforms: Azure AD, Linux, Network, Office 365, Windows, macOS
Sub-technique of: T1110

Adversaries may use password cracking to attempt to recover usable credentials, such as plaintext passwords, when credential material such as password hashes are obtained. OS Credential Dumping can be used to obtain password hashes, this may only get an adversary so far when Pass the Hash is not an option. Further, adversaries may leverage Data from Configuration Repository in order to obtain hashed credentials for network devices. Techniques to systematically guess the passwords used to compute hashes are available, or the adversary may use a pre-computed rainbow table to crack hashes. Cracking hashes is usually done on adversary-controlled systems outside of the target network. The resulting plaintext password resulting from a successfully cracked hash may be used to log into systems, resources, and services in which the account has access.

Detection: It is difficult to detect when hashes are cracked, since this is generally done outside the scope of the target network. Consider focusing efforts on detecting other adversary behavior used to acquire credential materials, such as OS Credential Dumping or Kerberoasting.
Data sources: Application Log: Application Log Content, User Account: User Account Authentication
T1110.001: Brute Force: Password Guessing
Tactics: Credential Access
Platforms: Azure AD, Containers, Google Workspace, IaaS, Linux, Network, Office 365, SaaS, Windows, macOS
Sub-technique of: T1110

Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to systematically guess the password using a repetitive or iterative mechanism. An adversary may guess login credentials without prior knowledge of system or environment passwords during an operation by using a list of common passwords. Password guessing may or may not take into account the target's policies on password complexity or use policies that may lock accounts out after a number of failed attempts. Guessing passwords can be a risky option because it could cause numerous authentication failures and account lockouts, depending on the organization's login failure policies. Typically, management services over commonly used ports are used when guessing passwords. Commonly targeted services include the following:  SSH (22/TCP)  Telnet (23/TCP)  FTP (21/TCP)  NetBIOS / SMB / Samba (139/TCP & 445/TCP)  LDAP (389/TCP)  Kerberos (88/TCP)  RDP / Terminal Services (3389/TCP)  HTTP/HTTP Management Services (80/TCP & 443/TCP)  MSSQL (1433/TCP)  Oracle (1521/TCP)  MySQL (3306/TCP)  VNC (5900/TCP) * SNMP (161/UDP and 162/TCP/UDP) In addition to management services, adversaries may "target single sign-on (SSO) and cloud-based applications utilizing federated authentication protocols," as well as externally facing email applications, such as Office 365.. Further, adversaries may abuse network device interfaces (such as `wlanAPI`) to brute force accessible wifi-router(s) via wireless authentication protocols. In default environments, LDAP and Kerberos connection attempts are less likely to trigger events over SMB, which creates Windows "logon failure" event ID 4625.

Detection: Monitor authentication logs for system and application login failures of Valid Accounts. If authentication failures are high, then there may be a brute force attempt to gain access to a system using legitimate credentials.
Data sources: Application Log: Application Log Content, User Account: User Account Authentication