The Operator Problem Nobody Wants to Admit
Most cloud hardening programs were written for an infrastructure that no longer exists. They were designed around virtual machines, network ACLs, and perimeter firewalls — artifacts of an era when a cloud environment meant lifting on-premises architecture into a hosted data center. Today, the environments that need hardening include serverless functions, container orchestration platforms, cross-tenant automation accounts, and AI-assisted pipeline tooling. The threat surface expanded faster than the hardening documentation kept up with.
The recent disclosure around default Azure Automation settings enabling cross-tenant identity takeover is exactly the kind of finding that exposes this gap. When a managed automation feature ships with a configuration that allows an attacker to pivot from one tenant to another using a legitimate identity chain, the problem isn't just a misconfiguration. It's evidence that the hardening checklist never included the automation plane at all. Most organizations running Azure Automation accounts for patch management or cost optimization workflows had no reason to audit that attack surface because their hardening programs didn't tell them to look there.
This article is for the security engineers and IT administrators who are responsible for cloud infrastructure security and already know the basics. The focus here is on the automation layer, cross-service identity chains, and operational practices that keep hardening programs current when the attack surface is actively changing underneath them.
Where Cloud Hardening Programs Stall Out
Hardening programs tend to stall at the compute layer. Benchmarks like CIS Controls and NIST SP 800-53 give strong guidance on operating system configuration, patch management, and network segmentation. Teams implement those controls, pass audits, and develop confidence that their environment is secure. The problem is that modern cloud attacks rarely start at the compute layer anymore.
The HelloNet campaign, which used the ViPNet update system to push malicious modules to connected endpoints, is an example of how attackers are moving through trusted software delivery channels rather than exploiting exposed services directly. The same logic applies to cloud automation: the update pipeline, the automation account, the managed identity, and the cross-service trust relationship are all attack vectors that traditional hardening frameworks treat as peripheral concerns.
P2P botnet campaigns complicate this further. Recorded Future and other threat intelligence providers have documented how modern attack infrastructure avoids centralized command-and-control by distributing coordination across peer nodes, making it harder to block at the network layer. When that traffic reaches your cloud workloads, it often looks like legitimate API activity from legitimate IP ranges. Hardening controls that focus on perimeter filtering miss it entirely.
Phase One: Immediate Actions You Can Take Today
Audit Managed Identity and Automation Account Permissions
The Azure cross-tenant identity takeover finding starts with a managed identity that has more permission than it needs and an automation configuration that was left at its default state. Start your audit by pulling a complete list of automation accounts in your environment and checking what managed identity or service principal each one uses. Then check what roles those identities hold at the subscription and management group level.
Any automation account with Owner or Contributor permissions at the subscription scope deserves immediate scrutiny. In most cases, automation workloads can operate with much narrower permissions scoped to specific resource groups. If you can't articulate why an automation account needs subscription-level access, treat it as a finding and reduce the scope now.
In AWS environments, the equivalent exercise is auditing IAM roles attached to Lambda functions, Step Functions, and EventBridge rules. Cross-account trust relationships are particularly worth examining. A Lambda function with a role that trusts an external account for invocation is a lateral movement path if that external account is compromised.
Review Cross-Service Trust Relationships
Cloud platforms make it easy to grant one service permission to call another. That convenience is also how attackers move laterally once they have a foothold. Pull your service-to-service trust relationships across the major platforms in your environment. In GCP, this means reviewing service account impersonation grants. In Azure, it means reviewing Managed Identity role assignments and any connections between Automation accounts, Logic Apps, and Azure Functions. In AWS, it means reviewing resource-based policies on S3 buckets, SQS queues, and KMS keys that allow cross-account access.
The goal isn't to remove all cross-service trust. The goal is to verify that every trust relationship is documented, intentional, and scoped as narrowly as the workload allows. Undocumented trust relationships are how attackers turn a limited foothold into broad access.
Enforce Separation Between Automation Credentials and Human Credentials
Automation accounts frequently share credential stores with human administrators, either because the tooling was set up quickly or because rotating automation credentials is operationally painful. Every automation workload that uses a human user account as its identity creates a situation where compromising that account — through phishing, credential stuffing, or a leaked token — gives an attacker the same access as a legitimate automation job. Use service principals, managed identities, or workload identity federation for automation. Remove human accounts from automation roles.
Phase Two: This Week's Priorities
Map Your Automation Attack Surface Explicitly
Spend time this week building an inventory of every automated process that has cloud API access. Include CI/CD pipelines, scheduled jobs, webhook handlers, event-driven functions, and any third-party integrations that receive API keys or OAuth tokens from your environment. For each one, document the identity it uses, the permissions that identity holds, what triggers it, and what external systems it can reach.
This inventory serves two purposes. First, it gives you a baseline for detecting anomalous automation activity. If your CI/CD pipeline normally calls the container registry and the Kubernetes API, a sudden call to IAM or the billing API from the same identity is suspicious and detectable. Second, it gives you a complete picture of your blast radius if any one automation credential is compromised.
Enable and Route Automation Activity Logs
Most cloud platforms generate detailed logs for automation activity that teams never configure to flow into their SIEM. Azure Automation Job logs, AWS CloudTrail events for Lambda execution roles, and GCP Cloud Audit Logs for service account activity are all sources that belong in your detection pipeline. If you have cross-tenant or cross-account configurations, make sure logs from those relationships are flowing into a centralized store that your security team controls, not just into account-local logging.
Configure alerts for specific high-risk patterns: automation credentials calling identity management APIs, new role assignments made by service principals, automation jobs that execute at unusual hours or with unusual duration, and any automation activity that originates from an IP range outside your expected cloud provider ranges.
Test Credential Revocation Procedures
Automation credentials that can't be quickly revoked are a liability. Run a tabletop exercise this week where your team simulates a compromised service principal or managed identity. Walk through the steps needed to revoke the credential, replace it, and restore automation functionality. Identify every dependency that breaks when the credential changes and build a rotation runbook that covers all of them.
Teams that have never practiced credential rotation discover during an actual incident that their automation pipelines have hard-coded key references, that rotating the credential breaks three downstream integrations they didn't know about, and that restoring normal operations takes hours. That recovery time is exactly the window an attacker needs.
Phase Three: Quarterly Hardening Program Improvements
Integrate the Automation Plane Into Your Hardening Benchmarks
CIS Benchmarks exist for major cloud platforms and they are updated regularly, but they tend to lag behind new service introductions. Supplement your benchmark coverage by explicitly adding automation plane controls to your internal hardening standard. Write controls that specify what permissions automation accounts may hold, how cross-tenant and cross-account trust must be configured and reviewed, how often automation credentials must be rotated, and what logging must be enabled for all automated workloads.
Review these controls quarterly and update them when your cloud provider introduces new automation capabilities. The Azure Automation cross-tenant finding caught organizations because the feature existed and had a dangerous default that nobody had written a control for yet. The only defense against that pattern is a hardening program that actively tracks new service introductions rather than relying on published benchmarks alone.
Bring Threat Intelligence Into Hardening Reviews
The modified CIA Hive attack toolkit entering criminal markets is a reminder that offensive tooling developed for nation-state operations eventually becomes accessible to lower-sophistication actors. When hardening programs treat threat intelligence as a separate function from infrastructure configuration, they miss the operational connection between what attackers are using and what controls need to be prioritized.
Make threat intelligence review a standing part of your quarterly hardening cycle. Look at what attack techniques have appeared in recent campaigns against cloud infrastructure specifically. When P2P botnet campaigns distribute coordination across cloud-hosted nodes, that's a signal to review your cloud egress controls and your detection coverage for unusual API call patterns originating from within your environment. When supply chain attacks move through update systems, that's a signal to review how your automation accounts authenticate to software repositories and what they're permitted to download and execute.
Validate Hardening Controls With Adversarial Testing
Configuration drift is one of the most persistent problems in cloud hardening. Controls that were correctly implemented six months ago may have changed due to an emergency change that wasn't reverted, a new team member who didn't know the policy, or a platform update that reset a default setting. Quarterly adversarial testing — whether through an internal red team exercise or an external engagement — is the most reliable way to find drift before attackers do.
Focus adversarial testing specifically on the automation and identity planes rather than defaulting to perimeter-focused exercises. Ask the testing team to attempt lateral movement through automation account credential compromise, cross-service trust abuse, and managed identity escalation. These are the paths that current attacks are actually using, and they're the paths your hardening controls need to demonstrably block.
Operationalizing Cross-Tenant and Multi-Account Awareness
The cross-tenant identity takeover class of vulnerability is particularly difficult to manage because it involves trust relationships that span organizational boundaries. Many enterprises run multiple Azure tenants for different business units or operate AWS Organizations structures with dozens of accounts. The security team that's responsible for hardening the environment may not have visibility into every tenant or account, and the automation workflows that cross those boundaries may have been set up by different teams at different times.
Establishing a cloud account and tenant inventory as a security asset is foundational to managing this risk. The inventory should capture every account or tenant, what automation workflows cross between them, what identities have cross-boundary permissions, and who is responsible for reviewing each relationship. Without that inventory, a hardening audit will miss cross-boundary trust relationships entirely because they're not visible from within any single account or tenant.
Build a review cadence into your governance process where cross-boundary trust relationships are specifically examined for necessity and scope. When a business unit requests a cross-tenant automation integration, the security review should require documentation of what the integration needs, what identity it will use, and what the minimum necessary permissions are. Approvals should come with an expiration date that forces a re-review rather than allowing relationships to persist indefinitely.
Monitoring What Hardening Controls Can't Prevent
Even a well-maintained hardening program doesn't prevent every attack. Default settings change, new services introduce new attack surfaces before benchmarks cover them, and supply chain attacks can deliver malicious code through trusted channels that your controls explicitly allow. Detection needs to operate as a parallel layer rather than a fallback for hardening failures.
For the automation plane specifically, build detection logic around behavioral baselines rather than static signatures. Your CI/CD pipeline should call the same APIs in roughly the same sequence every time it runs. Your scheduled automation jobs should execute within predictable time windows. Your managed identities should call APIs from within expected IP ranges. Deviations from those baselines are detection opportunities that don't require knowing what the attacker is doing — they only require knowing what normal looks like.
Cloud providers offer native anomaly detection capabilities that are worth enabling: AWS GuardDuty has specific findings for credential anomalies and cross-account activity; Azure Defender for Cloud covers managed identity and automation account anomalies; GCP Security Command Center includes service account anomaly detection. These native capabilities won't catch everything, but they generate findings for known-bad patterns with minimal configuration overhead and complement your SIEM-based detection rules.
Keeping the Hardening Program Alive Between Audits
The organizations that maintain effective cloud hardening programs treat it as an operational practice rather than a project. Audits happen at defined intervals, but the hardening program itself is continuously fed by threat intelligence, by incident findings, by red team results, and by cloud provider security announcements. When a cloud provider publishes a security advisory about a default configuration risk, the hardening team should have a process for evaluating whether that risk exists in the environment and adding a control if it does — without waiting for the next quarterly review cycle.
Assign ownership for the hardening program to a named individual or team with the authority to update internal standards and the operational bandwidth to do it. Programs that are owned by committees or treated as shared responsibility tend to stall when new findings require fast action. The Azure Automation cross-tenant finding should have triggered an immediate review in any organization running that service. That kind of response requires a program owner with a clear mandate, not a working group that needs to schedule a meeting.
Cloud infrastructure security hardening is not a static problem. The attack surface is changing every quarter as cloud providers introduce new services, as automation becomes more central to operations, and as attackers develop tooling purpose-built for cloud environments. The hardening program that covered your environment adequately last year needs active maintenance to cover it adequately today. The teams that treat that maintenance as continuous operational work rather than periodic project work are the ones whose hardening programs actually hold when the attack arrives.
