A Misconfiguration You Already Have
A mid-sized financial services firm completes a cloud migration to AWS. Their security team has deployed a WAF, enabled CloudTrail logging, and set up GuardDuty alerts. Six weeks later, a threat actor operating under the TAG-195 malware-as-a-service ecosystem gains persistent access through an over-permissioned IAM role attached to a Lambda function nobody had reviewed since the initial deployment. The attacker moves laterally, quietly enumerating S3 buckets and exfiltrating configuration data over three days before any alert fires. The initial foothold was not a zero-day. It was a default trust relationship that the team assumed would be addressed by the broader security tooling around it.
This scenario is not hypothetical. It reflects the consistent pattern emerging from incident response engagements across cloud environments in 2025 and into 2026. The tooling is present. The hardening fundamentals are absent. That gap is where attackers reliably enter.
What Cloud Hardening Actually Means in Practice
Cloud hardening is frequently discussed as a checklist activity. Run a CIS benchmark scan, resolve the findings, mark the task complete. The reality is that cloud infrastructure presents a continuously changing attack surface where new services are spun up, permissions are modified under deployment pressure, and network segmentation erodes as teams optimize for developer velocity.
Effective hardening is an operational discipline, not a one-time configuration pass. It encompasses identity and access management controls, network boundary enforcement, workload isolation, data protection at rest and in transit, logging and observability instrumentation, and the supply chain integrity of everything deployed into the environment. Each layer interacts with the others in ways that static checklists do not capture.
The GoSerpent threat campaign, which has evolved significantly in its data collection and exfiltration techniques, provides a useful case study here. GoSerpent targets cloud-hosted services precisely because the attack surface is more permeable than defenders assume. The campaign exploits overly broad outbound network permissions and misconfigured object storage policies to establish footholds and then exfiltrate sensitive data through legitimate-looking traffic channels. The hardening controls that would have interrupted this chain existed in every major cloud platform's native tooling. They were configured incorrectly or not at all.
Identity Is the Perimeter Now
In traditional network security, the perimeter was a physical or logical boundary. In cloud environments, identity is the perimeter. Every API call, every resource access, every service-to-service interaction is governed by an identity and a permission set attached to it. When those permissions exceed what is operationally required, the blast radius of any compromise expands immediately.
The principle of least privilege is well understood in theory and chronically under-implemented in practice. The friction points are real: development teams need to move quickly, and tightly scoped permissions require someone to define exactly what a given workload needs before it is deployed. That definition work gets skipped under deadline pressure, and the result is IAM roles and service accounts with permissions that make any attacker who obtains them effectively an administrator.
Practical implementation requires several concrete steps. First, establish a policy that no human user or service account is provisioned with standing administrative access. Elevated privileges should be granted through a just-in-time access mechanism with a defined expiration window. AWS IAM Identity Center, Azure Privileged Identity Management, and GCP's Privileged Access Manager all provide this capability natively. Second, implement a continuous IAM access review process that flags roles and service accounts that have not been used in a defined window, typically 30 to 90 days depending on the workload type. AWS IAM Access Analyzer, GCP Policy Intelligence, and Azure Access Reviews automate the detection of unused permissions. Third, enforce permission boundaries on all IAM roles used by workloads running in compute environments. Permission boundaries act as a ceiling on what any role can do regardless of what policies are attached to it, which limits the impact of privilege escalation attempts.
Network Segmentation at Cloud Scale
Cloud network architecture defaults to permissiveness. Security groups in AWS allow all outbound traffic by default. Azure NSGs require explicit rules but are frequently configured with wide allow ranges to avoid deployment failures. GCP firewall rules applied at the project level often cover far more resources than the team intends when they write them.
The Project CAV3RN command and control framework, which abuses Outlook calendar events for C2 communication and DNS AAAA records for configuration recovery, illustrates exactly why outbound traffic controls matter as much as inbound controls. Traditional perimeter controls block inbound threats. They do almost nothing to prevent an already-resident implant from communicating outbound over DNS or HTTPS to infrastructure that looks benign from a reputation perspective. Egress filtering that restricts outbound DNS to known resolvers, limits HTTPS destinations to a defined allowlist for critical workloads, and monitors for anomalous outbound traffic patterns would interrupt this attack chain before exfiltration begins.
Implement micro-segmentation using cloud-native controls. In AWS, this means VPC security groups scoped to specific source and destination resources rather than CIDR ranges, combined with VPC flow logs feeding into your SIEM. In Azure, use Application Security Groups to group workloads logically and apply NSG rules based on group membership rather than IP addresses. In GCP, enforce hierarchical firewall policies at the organization level to establish baseline rules that individual project teams cannot override.
For workloads that require internet access, route outbound traffic through a controlled egress point. AWS Gateway Load Balancer with a centralized inspection VPC, Azure Firewall Premium, or a Cloud NGFW deployment in GCP all provide this capability. Centralized egress inspection catches the command and control traffic that individual workload-level controls miss.
The Logging Instrumentation Problem
Cloud logging is abundant. Every major platform generates enormous volumes of events across compute, storage, identity, network, and management plane activity. The operational challenge is not generating logs but ensuring the right logs are collected, retained, and monitored with detection logic that surfaces meaningful signals.
Many organizations enable the highest-level audit logs, CloudTrail management events or Azure Activity Logs, and assume that coverage is sufficient. Management plane logs capture administrative actions against the control plane but miss data plane activity entirely. An attacker reading from an S3 bucket, querying a DynamoDB table, or enumerating Secrets Manager entries generates data plane events, not management plane events. Without S3 data event logging, CloudWatch Logs Insights queries on Lambda execution, and VPC flow log analysis, those actions are invisible.
The Cavern Manticore modular C2 framework, linked to Iranian threat actors, demonstrates how attackers operate within cloud environments while generating minimal control plane noise. The framework's modular design means individual components create narrow, low-volume activity patterns that blend into normal operational traffic. Detecting it requires behavioral baselines established from data plane logs, not just management plane audit trails.
Define a logging coverage matrix for your environment. For each cloud service in use, document which log types are available, which are enabled, where they are sent, what retention period applies, and what detection logic runs against them. This exercise consistently reveals gaps that assume coverage where none exists. Prioritize enabling S3 data event logging for all buckets containing sensitive data, CloudTrail Insights for anomaly detection on API call volumes, and DNS query logs through Route 53 Resolver or equivalent services in other platforms.
Secrets Management and Credential Hygiene
Hardcoded credentials in source code, container images, and environment variables remain one of the most consistent initial access vectors in cloud breaches. The Russian global webmail espionage campaigns documented in recent threat intelligence reporting have repeatedly leveraged credentials obtained from compromised development workstations or exposed configuration files to access cloud management consoles directly. Once an attacker has valid cloud credentials, especially those with broad permissions, the environment's technical security controls become largely irrelevant.
Enforce a strict prohibition on static credentials wherever dynamic credentials are available. AWS EC2 instance profiles, ECS task roles, and Lambda execution roles allow workloads to obtain temporary credentials from the metadata service. Azure Managed Identities and GCP Workload Identity provide equivalent capabilities. Static access keys should exist only in documented exceptional cases, should be rotated on a defined schedule of no longer than 90 days, and should generate an alert whenever they are used from an IP address or geographic location outside the expected operational baseline.
Deploy a secrets scanning capability across your CI/CD pipeline using tools such as Trufflehog, GitLeaks, or the native scanning capabilities in GitHub Advanced Security or GitLab. Secrets scanning should run on every commit and pull request, block merges on detected findings, and scan historical repository content for previously committed secrets that may still be valid.
Centralize secrets storage in AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager. Enforce rotation policies for database credentials, API keys, and certificates. Audit secrets access logs and alert on access patterns that deviate from the workload's established baseline, such as a service accessing a secret it has never accessed before or accessing a secret at an unusual time.
Container and Workload Hardening
Container environments introduce a distinct set of hardening requirements that sit between the underlying infrastructure and the application layer. The npm threat landscape report updated in July 2025 documented continued abuse of malicious packages to inject persistent access into containerized build pipelines and runtime environments. Supply chain integrity for container workloads requires controls at every stage from base image selection through build, registry storage, deployment, and runtime execution.
Start with base image hygiene. Use minimal base images, distroless images where the application supports it, or images derived from verified publisher sources. Implement image signing using Cosign and enforce signature verification at deployment time through admission controllers in Kubernetes or equivalent policy enforcement mechanisms in ECS and other container runtimes. Scan all images for known vulnerabilities before they reach the registry and block deployment of images with critical or high severity findings above a defined threshold.
At runtime, enforce non-root execution for all container workloads. Drop unnecessary Linux capabilities from container definitions. Apply seccomp profiles to restrict the system calls available to container processes. Use read-only root filesystems wherever possible and mount writable storage only where the application explicitly requires it. These controls significantly reduce the impact of a container escape or remote code execution vulnerability within a workload.
In Kubernetes environments, enforce Pod Security Admission at the namespace level, restricting privileged containers and host namespace sharing across the cluster. Implement network policies to control pod-to-pod communication. The default Kubernetes behavior allows all pods within a cluster to communicate with each other, which means a compromise of one workload gives an attacker the ability to probe all other workloads on the same cluster network.
Detecting Configuration Drift Before It Becomes an Incident
Cloud environments change constantly. Infrastructure as code provides a mechanism for managing desired state, but the gap between the IaC definition and the live environment grows over time through manual changes, automated remediation actions, and service-level changes that bypass the IaC pipeline entirely. Configuration drift is the mechanism by which a hardened baseline degrades into a vulnerable one.
Implement continuous configuration assessment using AWS Config with managed or custom rules, Azure Policy with Defender for Cloud, or GCP Security Command Center with Security Health Analytics. These tools evaluate resource configurations against defined baselines in real time and generate findings when configurations diverge. Connect these findings to your ticketing system with defined SLA requirements for remediation based on severity.
Run infrastructure drift detection on a scheduled basis by comparing the live state of deployed resources against the IaC source of record. Tools such as Terraform's plan output, CloudFormation drift detection, or Pulumi's refresh command identify resources that have been modified outside the IaC pipeline. Treat any detected drift as a security finding requiring investigation and remediation, not merely an operational inconsistency.
Establish change management controls that require all infrastructure modifications to flow through the IaC pipeline and receive security review for changes that affect security-relevant configurations. Security groups, IAM policies, encryption settings, and logging configurations should require an approval step before deployment to production environments.
Threat-Informed Hardening Priorities
The Siemens ROX II zero-day trilogy documented across multiple vulnerability disclosures in 2025 reinforced that industrial and operational technology increasingly overlaps with cloud infrastructure as organizations centralize monitoring and management in cloud environments. This convergence means that hardening priorities for cloud infrastructure need to account for threat actors who previously targeted OT environments exclusively but now route their campaigns through cloud management planes.
Map your hardening priorities to the threat actors and techniques most relevant to your sector. Use the MITRE ATT&CK Cloud Matrix as a structured framework for evaluating which techniques are being actively used against organizations in your industry and which controls in your environment address each technique. This exercise typically reveals gaps between the controls you believe are effective and the techniques attackers are actually deploying.
For organizations operating in sectors targeted by nation-state actors, this mapping should directly incorporate recent threat intelligence. The modular tooling upgrades observed in the TAG-195 MaaS ecosystem indicate continued investment in techniques that evade cloud-native detection controls by operating through legitimate cloud services and mimicking normal administrative activity. Controls that rely solely on reputation-based detection or known-bad indicator matching will miss this activity consistently. Behavioral detection that baselines normal administrative patterns and flags deviations is the appropriate response.
Hardening as a Continuous Operation
The organizations that maintain effective cloud security hardening treat it as an operational function with defined ownership, recurring activities, and measurable outcomes. This means scheduled hardening reviews that evaluate new services before they are adopted, regular red team exercises that test hardening controls against realistic attack scenarios, and a metrics program that tracks hardening coverage, configuration drift rates, and time to remediate findings.
Assign explicit ownership for hardening across the environment. Cloud security posture management is ineffective when it is treated as a shared responsibility with no clear accountable party. Designate owners for each cloud account or project, define their hardening responsibilities, and track their compliance through the CSPM tooling dashboards.
The threat landscape in mid-2026 is characterized by attackers who invest heavily in understanding cloud platform-specific behaviors and exploiting the assumptions defenders make about default configurations and native security tool coverage. The hardening controls described in this article address the attack patterns documented in current threat intelligence across multiple campaigns and targeting multiple sectors. They are implementable with native cloud tooling in most cases and require operational discipline more than specialized technology. That is precisely why they remain under-implemented despite being well understood: the work is sustained, unglamorous, and rarely receives organizational attention until a breach makes it unavoidable.
