T1078.004 Cloud Accounts

This diagnostic statement implements security controls and restrictions for remote user access to systems. Remote user access control involves managing and securing how users remotely access systems, such as through encrypted connections and account use policies, which help prevent adversary access.

This diagnostic statement includes implementation of controls for third-party access to an organization’s systems. Conditional access policies can be used to block logins from non-compliant devices or from outside defined IP ranges.

This diagnostic statement provides for secure system development, which includes ensuring that applications do not store sensitive data or valid account credentials insecurely (e.g., plaintext credentials in code, published credentials in repositories, or credentials in public cloud storage).

This diagnostic statement protects against Cloud Accounts through the use of privileged account management and the use of multi-factor authentication.

This diagnostic statement protects against Cloud Accounts through the use of privileged account management. Employing auditing, privilege access management, and just in time access protects against adversaries trying to obtain illicit access to critical systems.

This diagnostic statement protects against Valid Accounts: Cloud Accounts through the use of revocation of keys and key management. Employing key protection strategies for key material used as part of multi-factor authentication for valid accounts, limitations to specific accounts along with access control mechanisms provides protection against adversaries attempting to use valid accounts.

This diagnostic statement implements mechanisms and tools to mitigate potential misuse of privileged users and accounts. Continuous monitoring of role and attribute assignments and activity is essential to prevent and detect unauthorized access or misuse.

This diagnostic statement describes how the organization ensures users are identified and authenticated before accessing systems, applications, and hardware, with logical access controls permitting access only to authorized individuals with legitimate business needs. Logical access controls in relation to systems can refer to the use of MFA, user account management, and other role-based access control mechanisms to enforce policies for authentication and authorization of user accounts.

This diagnostic statement describes how the organization implement appropriate authentication requirements, including selecting mechanisms based on risk, utilizing multi-factor authentication where necessary, and safeguarding the storage of authenticators like pins and passwords to protect sensitive access credentials.

This diagnostic statement protects against Cloud Accounts through the use of hardened access control policies, secure defaults, password complexity requirements, multifactor authentication requirements, and removal of terminated accounts.

This control may generate alerts based on unfamiliar or suspicious IP addresses, TOR exit node, and anonymous access.

This control may alert on logon events that are suspicious. This includes logins from unusual locations, logins from suspicious IP addresses, and users that do not commonly access the resource. These alerts may limit the ability of an attacker to utilize a valid cloud account to access and manipulate Azure databases.

This control's "Deprecated accounts should be removed from your subscription" and "Deprecated accounts with owner permissions should be removed from your subscription" recommendation can lead to removing accounts that should not be utilized from your subscriptions thereby denying adversaries the usage of these accounts to find ways to access your data without being noticed. Likewise, the recommendations related to External account permissions can also mitigate this sub-technique. Because these are recommendations and only limited to deprecated and external accounts, this is scored as Minimal.

This control triggers an alert when there is a change in the access pattern to an Azure Cosmos account based on access from an unusual geographical location. False positives are fairly likely and misuse from a typical location is not covered, so score is Minimal. Relevant alert is "Access from an unusual location to a Cosmos DB account"

This control may provide recommendations to audit and restrict privileges on Azure cloud accounts. This control may provide information to reduce surface area for privileged access to Azure.

This control can be used to implement the least-privilege principle for account management and thereby limit what an adversary can do with a valid account.

Advanced Protection Program enables the use of a security key for multi-factor authentication. Integrating multi-factor authentication (MFA) as part of organizational policy can greatly reduce the risk of an adversary gaining control of valid credentials that may be used for additional tactics such as initial access, lateral movement, and collecting information.

This control may be able to detect when adversaries use valid cloud accounts to elevate privileges through manipulation of IAM or access policies. This monitoring can be fine tuned to specific assets, policies, and organizations.

This control can be used to mitigate malicious attacks of cloud accounts by implementing multi-factor authentication techniques or password policies.

GKE Enterprise incorporates the Anthos Config Management feature to create and manage Kubernetes objects across multiple clusters at once. PodSecurityPolicies can be enforced to prevent Pods from using the root Linux user. Based on the medium detection coverage, this sub-technique was scored as partial.

This control protects against malicious use of cloud accounts and gaining access to them. This control may mitigate the impact of compromised valid accounts by enabling fine-grained access policies and implementing least-privilege policies. MFA can provide protection against an adversary that obtains valid credentials by requiring the adversary to complete an additional authentication process before access is permitted.

Protects access to applications hosted within cloud and other premises.

Identity Platform lets you add Google-grade authentication to your apps and services, making it easier to secure user accounts and securely managing credentials. MFA can provide protection against an adversary that obtains valid credentials by requiring the adversary to complete an additional authentication process before access is permitted.

Adversaries may obtain and abuse credentials of a cloud account by gaining access through means of Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Policy Intelligence role recommendations generated by IAM Recommender help enforce least privilege principals to ensure that permission levels are properly managed.

ReCAPTCHA Enterprise allows users to configure Multifactor Authentication (MFA) to verify user's identity by sending a verification code by email or SMS (known as an MFA challenge). When ReCAPTCHA Enterprise assesses that user activity to exceeds a predetermined threshold (by the developer), it can trigger an MFA challenge to verify the user. This increases the likelihood that a compromised account will be prevented from impacting the system. Since ReCAPTCHA Enterprise does not require a MFA challenge for all user activity, it has been given a rating of Partial.

Adversaries may attempt to obtain credentials of existing account through privilege escalation or defense evasion. IAM audit logging in GCP can be used to determine roles and permissions, along with routinely checking user permissions to ensure only the expected users have the ability to list IAM identities or otherwise discover cloud accounts.

SCC ingests Cloud Audit logs to detect when an external member is added to a privileged group with sensitive permissions or roles. This security solution protects against compromised cloud accounts used to maintain persistence and harvest sensitive data. Because of the near-real time temporal factor to detect against this cyber-attack the control was graded as significant.

Amazon Cognito has the ability to alert and block accounts where credentials were found to be compromised elsewhere (compromised credential protection). The service also detects unusual sign-in activity, such as sign-in attempts from new locations and devices and can either prompt users for additional verification or block the sign-in request. There was insufficient detail on the operation of these capabilities and therefore a conservative assessment of a Partial score has been assigned.

Listed findings above flag instances where there are indications of account compromise.

The following AWS Config managed rules can identify configuration problems that should be fixed in order to ensure multi-factor authentication (MFA) is enabled properly, which can provide protection against attempted misuse of cloud accounts: "iam-user-mfa-enabled", "mfa-enabled-for-iam-console-access", "root-account-hardware-mfa-enabled", and "root-account-mfa-enabled". All of these controls are run periodically. The following AWS Config managed rules can identify configuration problems that should be fixed in order to ensure that appropriate AWS Identity and Access Management (IAM) policies are in place to enforce fine-grained access policies and mitigate the impact of compromised valid accounts: "iam-customer-policy-blocked-kms-actions", "iam-inline-policy-blocked-kms-actions", "iam-no-inline-policy-check", "iam-group-has-users-check", "iam-policy-blacklisted-check", "iam-policy-no-statements-with-admin-access", "iam-policy-no-statements-with-full-access", "iam-role-managed-policy-check", "iam-user-group-membership-check", "iam-user-no-policies-check", and "ec2-instance-profile-attached" are run on configuration changes. "iam-password-policy", "iam-policy-in-use", "iam-root-access-key-check", "iam-user-mfa-enabled", "iam-user-unused-credentials-check", and "mfa-enabled-for-iam-console-access" are run periodically. The "access-keys-rotated" managed rule ensures that IAM access keys are rotated at an appropriate rate. Given that these rules provide robust coverage for a variety of IAM configuration problems and most are evaluated on configuration changes, they result in an overall score of Significant.

This control may mitigate the impact of compromised valid accounts by enabling fine-grained access policies and implementing least-privilege policies. MFA can provide protection against an adversary that obtains valid credentials by requiring the adversary to complete an additional authentication process before access is permitted.

The Access Analyzer tool may detect when an external entity has been granted access to cloud resources through use of access policies. This tool will scan upon any change to access policies or periodically within 24 hours.

The following AWS IoT Device Defender audit checks can identify potentially malicious use of valid cloud credentials by AWS IoT devices, which may indicate that devices have been compromised: "CA certificate revoked but device certificates still active" ("REVOKED_CA_CERTIFICATE_STILL_ACTIVE_CHECK" in the CLI and API) indicates that device certificates signed using a revoked CA certificate are still active, which may indicate that devices using those certificates are controlled by an adversary if the CA certificate was revoked due to compromise. "Device certificate shared" ("DEVICE_CERTIFICATE_SHARED_CHECK" in the CLI and API), "Revoked device certificate still active" ("REVOKED_DEVICE_CERTIFICATE_STILL_ACTIVE_CHECK" in the CLI and API), and "Conflicting MQTT client IDs" ("CONFLICTING_CLIENT_IDS_CHECK" in the CLI and API) can indicate that devices are in use with duplicate certificates and/or IDs and/or certificates that have been revoked due to compromise, all of which suggest that an adversary may be using clones of compromised devices to leverage their access. The following AWS IoT Device Defender cloud-side detection metrics can identify potentially malicious use of valid cloud credentials by IoT devices, which may indicate that devices have been compromised: "Source IP" ("aws:source-ip-address") values outside of expected IP address ranges may suggest that a device has been stolen. "Authorization failures" ("aws:num-authorization-failures") counts above a typical threshold may indicate that a compromised device is attempting to use its connection to AWS IoT to access resources for which it does not have access and being denied. High counts for "Disconnects" ("aws:num-disconnects"), especially in conjunction with high counts for "Connection attempts" ("aws:num-connection-attempts"), which include successful attempts, may indicate that a compromised device is connecting and disconnecting from AWS IoT using the device's associated access. Coverage factor is partial for these metrics, checks, and mitigations, since they are specific to use of cloud accounts for AWS IoT access and actions, resulting in an overall score of Partial.

The following AWS IoT Device Defender audit checks and corresponding mitigation actions can identify and in some cases resolve configuration problems that should be fixed in order to limit the potential impact of compromised accounts with access to AWS IoT resources: The "Authenticated Cognito role overly permissive" ("AUTHENTICATED_COGNITO_ROLE_OVERLY_PERMISSIVE_CHECK" in the CLI and API) audit check can identify policies which grant excessive privileges and permissions for AWS IoT actions to Amazon Cognito identity pool roles. The "Unauthenticated Cognito role overly permissive" ("UNAUTHENTICATED_COGNITO_ROLE_OVERLY_PERMISSIVE_CHECK" in the CLI and API) audit check can identify policies which grant excessive privileges and permissions for AWS IoT actions to Amazon Cognito identity pool roles and do not require authentication, which pose a substantial risk because they can be trivially accessed. The "AWS IoT policies overly permissive" ("IOT_POLICY_OVERLY_PERMISSIVE_CHECK" in the CLI and API) audit check can identify AWS IoT policies which grant excessive privileges and permissions for AWS IoT actions and supports the "REPLACE_DEFAULT_POLICY_VERSION" mitigation action which can reduce permissions to limit potential misuse. The "Role alias allows access to unused services" ("IOT_ROLE_ALIAS_ALLOWS_ACCESS_TO_UNUSED_SERVICES_CHECK" in the CLI and API) and "Role alias overly permissive" ("IOT_ROLE_ALIAS_OVERLY_PERMISSIVE_CHECK" in the CLI and API) audit checks can identify AWS IoT role aliases which allow connected devices to authenticate using their certificates and obtain short-lived AWS credentials from an associated IAM role which grant permissions and privileges beyond those necessary to the devices' functions and should be fixed in order to prevent further account compromise from compromised devices. Coverage factor is partial for these checks and mitigations, since they are specific to use of cloud accounts for AWS IoT access and actions, resulting in an overall score of Partial.

This control may protect against malicious use of cloud accounts by implementing service control policies that define what actions an account may take. If best practices are followed, AWS accounts should only have the least amount of privileges required.

AWS Security Hub detects suspicious activity by AWS accounts which could indicate valid accounts being leveraged by an adversary. AWS Security Hub provides these detections with the following managed insights. AWS principals with suspicious access key activity Credentials that may have leaked AWS resources with unauthorized access attempts IAM users with suspicious activity AWS Security Hub also performs checks from the AWS Foundations CIS Benchmark and PCI-DSS security standard that, if implemented, would help towards detecting the misuse of valid accounts. AWS Security Hub provides these detections with the following checks. 3.1 Ensure a log metric filter and alarm exist for unauthorized API calls 3.2 Ensure a log metric filter and alarm exist for Management Console sign-in without MFA 3.3 Ensure a log metric filter and alarm exist for usage of "root" account 3.4 Ensure a log metric filter and alarm exist for IAM policy changes 3.6 Ensure a log metric filter and alarm exist for AWS Management Console authentication failures [PCI.CW.1] A log metric filter and alarm should exist for usage of the "root" user By monitoring the root account, activity where accounts make unauthorized API calls, and changes to IAM permissions among other things, it may be possible to detect valid accounts that are being misused and are potentially compromised. This is scored as Significant because it reports on suspicious activity by AWS accounts.

This control may protect against malicious use of valid accounts by implementing fine grained and least privilege access through use of permission sets (a collection of administrator-defined policies that AWS SSO uses to determine a user's effective permissions to access a given AWS account). The ability to reduce the set of credentials and accounts needed for a user allows for simpler and safer access and privilege management.