Why Allowlisting Alone Is Not Sufficient to Protect Cloud Workloads

As someone who has spent years working with cloud environments, I’ve seen firsthand how the landscape is changing. Cloud workloads operate in dynamic environments, interacting with diverse services, APIs and third-party platforms.

While allowlisting outbound destinations is a common security practice, it’s operationally challenging and difficult to keep allowlists current as cloud services, workloads and endpoints rapidly evolve. Managing third-party dependencies adds complexity, and even trusted domains can be hijacked or compromised, limiting the effectiveness of allowlisting alone.

Relying solely on allowlisting is like locking your front door but leaving the windows open. This blog explores both the operational limitations and the security gaps of allowlist-based approaches, illustrating real-world breach scenarios that expose these vulnerabilities.

Limitations of Allowlist-Only Security

1. Allowlisted Destinations Can Be Compromised
   Even trusted, allowlisted services, like GitHub, Dropbox or Slack, can be abused by attackers for data exfiltration or command and control (C2).

   Example: Attackers use GitHub repositories or Gist as a C2 channel. If GitHub is allowlisted, malicious workloads can still “phone home.”

2. Third-Party Dependencies or SaaS Integrations Can Be Hijacked
   Cloud workloads often communicate with APIs or services (e.g., NPM, PyPI, S3 buckets) that can be tampered with.

   Example: The SolarWinds Orion breach included an update from a trusted, signed source that was weaponized. If SolarWinds’ update server was allowlisted, the malicious update would still go through.

3. DNS Tunneling or Domain Fronting Inside Allowed Domains
   DNS requests to allowed domains (like *.google.com) can be used to tunnel data.

   Example: The Cobalt Strike beacon can use DNS tunneling. Even if the domain is allowed, the data going over it is malicious.

4. IP Allowlisting in Cloud Is Fragile
   Many SaaS and cloud services use shared IP pools or content delivery networks (CDNs), like Cloudflare. A malicious service hosted on the same IP range can bypass filters.

   Example: An attacker uses the same CDN as an allowlisted SaaS to exfiltrate data.

5. Zero-Day Exploits or Supply Chain Attacks
   Workloads can be breached due to vulnerabilities in libraries, containers or APIs, and those workloads may then make malicious outbound calls to allowlisted services.

   Example: In the Log4Shell (Log4j) vulnerability, exploited systems could make outbound Java Naming and Directory Interface (JNDI) lookups to allowlisted Lightweight Directory Access Protocol (LDAP) servers hosting malicious payloads.

6. Misconfigurations in Allowlists
   If a domain like *.amazonaws.com is allowlisted, a compromised workload can access attacker-controlled Amazon S3 buckets or Elastic Compute Cloud (EC2) instances.

   Example: Attacker sets up malicious content in a region-specific S3 bucket (malicious-bucket.s3.us-west-2.amazonaws.com) that is covered by a broad allowlist.

Real-World Breach Examples

Sophisticated attackers have developed techniques to bypass allowlisting, demonstrating that even traffic restricted to “approved” destinations can facilitate malicious communications through legitimate channels.

1. Domain Fronting: Exploiting CDNs
   Domain fronting is a potent method to evade allowlisting by masking malicious traffic as legitimate communication via CDNs. Using HTTPS encryption, attackers disguise traffic to malicious destinations as interactions with allowlisted domains. For example, if a workload is allowed to connect to a legitimate Akamai-hosted service like www.disney[.]com, it can communicate with any domain on the same IP (e.g., 23.214.98.69), as firewalls only see the allowlisted CDN domain during DNS and TLS negotiations.

   Tools like Psiphon have exploited domain fronting to bypass network restrictions, enabling malware in cloud workloads to establish C2 channels while appearing to interact with approved services.¹

2. Compromised SaaS Services: The VEILDrive Campaign
   The 2024 VEILDrive campaign highlights how attackers leverage trusted, allowlisted SaaS platforms for persistent control. This attack used Microsoft services like Teams, SharePoint, Quick Assist and OneDrive as C2 channels, with a unique OneDrive-based method to manage malware. Since Microsoft services are often allowlisted, such attacks are challenging to detect.
3. Cloud Storage Compromise: AWS S3 Bucket Attacks
   Amazon S3 buckets, frequently allowlisted for business needs, can become attack vectors when misconfigured or compromised. Attackers can use them to host malicious content or operate C2 servers. Research indicates 46 percent of S3 buckets may be misconfigured, posing significant risks.

   Notable breaches include the 2020 Twilio incident, where attackers accessed an unprotected S3 bucket to upload a potentially harmful software development kit (SDK), and the 2021 Premier Diagnostics breach, exposing over 50,000 patient records due to publicly accessible buckets.

Best Practices to Strengthen Security

• Use Protective DNS solutions like Infoblox Threat Defense™ to spot anomalies in DNS traffic.
• Enrich policies with threat intelligence to block known malicious destinations within allowlisted categories.
• Apply deep packet inspection and behavioral analytics for suspicious activity detection.
• Implement Zero Trust Segmentation and least-privilege access to limit network permissions.
• Monitor cloud-native logs and telemetry using SIEM/SOAR tools.

Conclusion

Allowlisting is a critical security layer for cloud workloads, but it’s not enough on its own. Sophisticated attackers can exploit legitimate channels using domain fronting, compromised SaaS services, misconfigured cloud storage and implementation flaws. To protect your cloud workloads, you need a layered defense that incorporates Protective DNS, threat intelligence, behavioral monitoring and Zero Trust principles. Organizations must evolve beyond simple allow/deny rules to counter both external threats and internal misuse of approved pathways.

Footnotes

1. Blocking-resistant communication through domain fronting, Fifield, David, Lan, Chang, Hynes, Rod, Wegmann, Percy, Paxson, Vern, De Gruyter, June 8, 2015.