Companies are increasingly relying on cloud-based infrastructure, especially as more of their employees are working remotely — and may continue to do so. Public, private and hybrid clouds allow access to data and other assets, no matter where an employee is located — but they also create opportunities for cyberattackers to exploit.
In recent months, we have observed increasingly sophisticated operations in which financially motivated adversaries are using cloud application programming interface (API) keys to harvest information assets for ransom or sale. They are also often seeking other keys and passwords to facilitate further access, enabling them to repeat the cycle. With many organizations moving their resources to the cloud and attackers looking to exploit any weaknesses, cloud security must be a top priority.
New Attack Surfaces
Internet-as-a-service (IaaS) API key theft has opened a vast new attack surface, giving adversaries easy access to critical controls and data assets when appropriate protection is not in place. Many recent cases have involved static credentials that were not protected by multi-factor authentication (MFA), IP address-based restrictions or automatic rotation. Previously, when threat actors harvested API keys from public source code repositories, it was typically a crime of opportunity. Now, it’s become targeted, and there are many cases in which attackers actively sought cloud IaaS API keys in client and third-party infrastructure. In virtually all cases, these long-lived API keys were an unnecessary liability as they could have been replaced with ephemeral credentials issued through the underlying cloud infrastructure.
Detection Time Is Key
In addition, detection times can range from hours to months, and in many cases, data exfiltration has occurred before detection. Host-level compromise in the cloud continues, and many cases involve “shadow IT” cloud deployments — deployments that receive limited security oversight and investment. The Services team has observed gaps in endpoint (instance/VM) detection capabilities, misconfigured logging, misconfigured firewall rules, and lack of system and application vulnerability management.
In some cases, security staff were already stretched thin in their efforts to secure on-premises resources, or they lacked familiarity and experience with cloud environments. In others, serious incidents affected infrastructure that was already slated to be decommissioned prior to compromise. The Services team considers these trends a contributing factor in compromises resulting from both nation-state and financially motivated operations.
We continue to recommend the following practices to help organizations prevent breaches of their cloud infrastructure:
Avoid using static API keys anywhere. Static keys pose a significant risk because they allow enduring access to large amounts of often-sensitive data. Instead, use ephemeral credentials for automated cloud activity and enforce the usage of these credentials only from authorized IP address space. Also, require MFA for all user-originated cloud activity.
Proactively manage cloud accounts and permissions. Begin this process by conducting an account inventory to ensure every resource has an identified owner/responsible party. Next, use a cloud account factory model to ensure new cloud accounts comply with security expectations from the start. You should also review permissions in legacy or to-be-decommissioned cloud accounts for excessive public access to hosts and storage services. Finally, find cloud accounts/subscriptions that are not being monitored by looking for references to unrecognized cloud accounts. This can be achieved by collaborating with the finance department to find unrecognized cloud subscriptions.
Enable logging and alerting. Enable detailed logging, including API and data object access logging, to the maximum extent affordable. Also, invest in and tune automated alerting to rapidly identify incidents and revert improper configuration changes.
Regularly review firewall rules on the cloud. Use automated and manual firewall ruleset reviews to avoid global-permit rules in both inbound and outbound contexts.
Originally published on the CrowdStrike Blog, June 9, 2020, by Thomas Etheridge.
