Securing the cloud is a race against time. Developers are building systems and applications faster than ever, but this creates more risks and vulnerabilities for hackers to exploit. With limited time and resources, companies face a dilemma — should they invest in risk mitigation to build stronger defenses, or focus on threat detection to quickly address breaches? 

The truth is that both are crucial. By integrating risk and threat insights, teams can prioritize the actions that matter most, like fixing critical vulnerabilities and stopping the most dangerous threat actors. 

As security researchers, we’re constantly analyzing and anticipating cyber threats. We know that understanding and effectively prioritizing threats starts with identifying the enemy. In this blog, we’ll explore the motivations of bad actors, the top threats the Lacework Labs team is seeing, and practical ways to lock down your cloud and protect your data.

Who’s behind the threats? 

In the cloud, we are typically concerned about two categories of threat actors: State sponsored and criminal. State sponsored actors engage in espionage and data theft to advance their government’s agendas. They range from moderately sophisticated to highly advanced.

Criminals are financially motivated. They hijack resources for crypto mining, steal data for ransom, and disrupt services via distributed denial-of-service (DDoS) attacks. 

Top threats in the cloud right now

Attackers frequently breach cloud environments using leaked access keys found in code repositories.

Cloud control plane: Compromised credentials

The cloud control plane is the central control system that helps people manage and use cloud resources. Different cloud service providers (e.g., AWS, Microsoft Azure, Google Cloud) have their own implementations of the cloud control plane, but the fundamental concepts and functions are similar across these platforms. 

In the cloud control plane, identity compromises are the types of threats that Lacework Labs is seeing most prominently today. The vast majority of attacks on the cloud control plane require initial access to a cloud identity. Once inside the attackers can escalate their privileges and carry out their objectives. 

How are these credentials getting leaked? They’re sometimes accidentally included in code that employees commit to public code repositories. Attackers are also using practices like phishing, which tricks individuals into revealing sensitive information. We are also observing attackers finding unsecured config files that contain these credentials. And access brokers are selling stolen credentials on the dark web and other underground forums. Because attackers use stolen legitimate credentials, they often appear as legitimate users, which makes these attacks particularly difficult to detect. 

Workload: Mass scanning for vulnerabilities

Workloads, which include computing resources like Linux and Windows hosts, are susceptible to compromise. Workload threats often begin with mass scanning for exposed vulnerabilities. This scanning is typically conducted using out-of-band application security tools (OAST), which penetration testers originally designed to identify vulnerabilities and help companies fix those; but attackers have since repurposed these tools to scan the internet for vulnerabilities that enable them to break into cloud environments. One of the most popular tools for this purpose is Project Discovery, which includes Nuclei templates. These templates are YAML files that contain all the necessary data to test for specific vulnerabilities; many times, for newly identified Common Vulnerabilities and Exposures (CVEs). When a new CVE is published, security researchers use it to gauge its impact on the internet, but threat actors exploit the same information to compile lists of potential targets.

Nuclei templates are used for both threat intelligence and exploits. 

Once the scanning process uncovers possible targets, the next phase is exploitation, where the threat actors deploy various forms of malware. The typical procedure includes running a script that prepares the system to install these malicious programs. We often see modules for lateral movement, cryptojacking, and denial of service attacks being installed. More concerningly, there is evidence that attackers are attempting to extend their reach from individual workloads to the broader cloud control plane.

Detect runtime threats, visualize activity, and automate alerts to effectively secure Kubernetes. 

Kubernetes: A dual-threat

As Kubernetes orchestrates container management, it presents a dual-threat landscape: the control plane and the containers themselves. The control plane of Kubernetes includes the API server and any component that allows control over the orchestration server itself — for example, exploiting internet-facing applications, using access tokens for lateral movement, unsecured dashboards, and API abuse) — and the act of escaping from containers or pods to the host, which can facilitate further pivots into the cloud control plane.

Malware (e.g., Kinsing) targets Kubernetes by exploiting weakly configured containers and flawed images. 

When it comes to initial access in the context of Kubernetes, the Kinsing malware, for example, targets vulnerabilities such as weakly configured PostgreSQL containers and flawed images like WebLogic and WordPress. It propagates by scanning for known vulnerabilities. Typically, a Command and Control (C2) channel is established through exploit tools or reverse shell activity. What’s interesting about escaping from these pods is the wide range of techniques available, from exploiting poorly configured containers to executing complex, technical exploits. Threat actors typically seek to deploy new pods or containers in a misconfigured state, making it easy for them to transition from the container to the host. It’s a sort of workaround where they get around the fence by creating their own fence with a hole in it.

Software as a Service: An expanding target for attackers to go after your data

The attack surface has expanded significantly with the adoption of Software as a Service (SaaS) applications, witnessing 41% increase in the average number of SaaS applications used from 2021 to 2023, according to the Thales Cloud Security Study. 

Several notable attacks on SaaS applications were recorded last year. In one case, Mandiant reported attackers accessing a customer engagement SaaS tool and uploading reports for exfiltration from the victim’s AWS account. In another, Obsidian discovered that the 0mega ransomware group carried out data extortion by gaining access to the admin account of a victim’s SharePoint account. Adaptive Shield security researchers uncovered a new attack vector stemming from a vulnerability in Microsoft’s OAuth application registration, which allowed attackers to use Exchange’s legacy API to create hidden forwarding rules in Microsoft 365 mailboxes. Additionally, Mandiant observed the financially-motivated threat group FIN11 conducting two significant campaigns that exploited zero-day vulnerabilities in managed file transfer software from Fortra and MOVEit, leading to data theft and extortion operations that impacted hundreds of organizations in the first half of 2023.

Software supply chain attacks: Potentially devastating

Another crucial aspect of the attack surface, which ties all these elements together, is the software supply chain. 

There are two types of code involved in developing cloud applications: first-party code, which is the code developed by your company, and third-party code, which consists of existing code developed by someone else (e.g., open-source software) that is used within your software. As applications expand in scale, they begin to incorporate more and more first- and third-party code, which is difficult to keep track of. This also makes the software supply chain a lucrative target for threat actors, commonly using attack vectors like compromised code repositories, malicious third-party libraries, or insecure API integrations. Ideally, organizations can detect and stop these attacks soon after the bad actor gains unauthorized access to an environment; but sometimes, we see these result in full system takeovers. Real-world incidents, such as the SolarWinds breach, have demonstrated the widespread and potentially devastating impact of these attacks. 

In APT scenarios, we often witness the compromise of managed service providers, which are then used as conduits to infiltrate the customer base of those organizations. A notable instance of this was the compromise of JumpCloud, a cloud-based IT management service. This breach was part of a software supply chain attack strategy intended to penetrate multiple high-value networks. The attack has been attributed to a North Korean state-sponsored APT, as indicated by shared Indicators of Compromise (IOCs). This APT group was also observed attacking platforms like GitHub and the 3CXDesktopApp. In this case, JumpCloud was utilized as a pivot point to potentially compromise other companies, highlighting the critical importance of software supply chain security and the ripple effect they can have if not contained quickly. 

The gray area of the shared responsibility model 

The delineation of security responsibilities between customers and cloud service providers (CSPs) is not always clear. The CSP is generally responsible for securing their own data centers and the software running on their servers, and the customer is responsible for securing anything they bring into those environments (and configure). But this distinction isn’t always clear-cut and often falls into a gray area, especially because each CSP follows a slightly different version of the model. And sometimes vulnerabilities require action from both the CSP and the customer (e.g., cloud providers might need to fix a bug; while the customer must take steps on their end to mitigate the threat). Challenges can arise if the customer is unaware of the vulnerability or if implementing the necessary changes is difficult for their engineering team. Threat actors know this, and often try to take advantage of this ambiguity. The Lacework Labs team recently observed an example of this, when we saw a significant uptick in credential compromises that were traced to increased exploitation of a three-year-old server-side request forgery (SSRF) vulnerability to access AWS instance metadata service (IMDS) v1 (note: IMDSv2 has been available for four years to mitigate SSRF attacks to retrieve instance credentials. Affected versions are only Grafana 6 and 7. AWS Managed Grafana does not offer those versions and the current GA version is not affected by
this CVE).

Mitigation strategies

There are an overwhelming number of threats in the cloud — and as long as cloud usage continues to grow, threat actors will continue to take advantage. To create an effective cloud security strategy, organizations need to take a realistic approach and prioritize the key areas and actions that will have the greatest impact at their company. This will differ from company to company; but based on our observations in the past year, these are a few main areas that the Lacework Labs team recommends focusing on: 

• Ingress control: This involves controlling what can access your environment from the internet. Implementing ingress control can be challenging because attackers often exploit vulnerabilities through primary access points; however, this is an effective way to mitigate direct threats. 
• Egress control: This strategy is crucial for mitigating malware-based threats. It restricts servers to communicate only with whitelisted external services. This is particularly important when dealing with zero-day vulnerabilities like Log4j, which often require an external callback to execute malware. By limiting outbound communication, you can mitigate the impact even if your system is compromised.
• Least privilege: Prioritize the principle of least privilege, especially in the context of service provider control planes and credential compromises, which are major threats we are observing today. 
• Unphishable second factors: A few years ago, there was a push for widespread adoption of multi-factor authentication (MFA). However, not all MFA methods are equally secure. Attacks on SMS and push notifications are common. It is recommended to use more secure methods like YubiKeys, which require physical presence, adding an extra layer of security.
• Communicate and specify who is responsible for what: The issues presented by shared responsibilities in cloud security won’t be resolved overnight. The first step is educating people about their responsibilities and the actions taken by their cloud provider. It’s essential to understand where communications from service providers originate and to respond to them promptly.
• SaaS security: Often overlooked, SaaS security is crucial since it may not fall under the conventional scope of data protection. Consider implementing SaaS-Security Posture Management solutions, now a vital component of comprehensive security strategies. 

With Lacework, risk mitigation is informed by threat insights and threat management is informed by risk insights.

How Lacework can help

Lacework believes that the most effective security strategies strike the right balance between risk mitigation and threat management, using key information from each to provide context-rich and actionable alerts, greatly improving time to remediation and helping avoid burnout.

Want to see for yourself how Lacework helps detect the latest threats with our patented approach? Get complete access to our platform with our 14-day free trial here. 

Categories

• Blog
• Cloud Security
• Research

• CNAPP
• CSPM
• CWPP
• K8s
• Lacework Labs
• Vulnerabilities (CVEs)