As someone who has spent years working with cloud environments, I\u2019ve seen firsthand how the landscape is changing. Cloud workloads operate in dynamic environments, interacting with diverse services, APIs and third-party platforms.<\/p>\n
While allowlisting outbound destinations is a common security practice, it\u2019s 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.<\/p>\n
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.<\/p>\n
Example<\/strong>: Attackers use GitHub repositories or Gist as a C2 channel. If GitHub is allowlisted, malicious workloads can still \u201cphone home.\u201d<\/li>\n Example<\/strong>: The SolarWinds Orion breach included an update from a trusted, signed source that was weaponized. If SolarWinds\u2019 update server was allowlisted, the malicious update would still go through.<\/li>\n Example<\/strong>: The Cobalt Strike beacon can use DNS tunneling. Even if the domain is allowed, the data going over it is malicious.<\/li>\n Example<\/strong>: An attacker uses the same CDN as an allowlisted SaaS to exfiltrate data.\n<\/li>\n Example<\/strong>: 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.\n<\/li>\n Example<\/strong>: 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.<\/li>\n<\/ol>\n Sophisticated attackers have developed techniques to bypass allowlisting, demonstrating that even traffic restricted to \u201capproved\u201d destinations can facilitate malicious communications through legitimate channels.<\/p>\n 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.1<\/sup><\/li>\n Notable breaches include the 2020 Twilio incident<\/strong><\/a>, where attackers accessed an unprotected S3 bucket to upload a potentially harmful software development kit (SDK), and the 2021 Premier Diagnostics<\/strong><\/a> breach, exposing over 50,000 patient records due to publicly accessible buckets.<\/li>\n<\/ol>\n Allowlisting is a critical security layer for cloud workloads, but it\u2019s 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.<\/p>\n
\nCloud workloads often communicate with APIs or services (e.g., NPM, PyPI, S3 buckets) that can be tampered with.<\/p>\n
\nDNS requests to allowed domains (like *.google.com) can be used to tunnel data.<\/p>\n
\nMany 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.<\/p>\n
\nWorkloads can be breached due to vulnerabilities in libraries, containers or APIs, and those workloads may then make malicious outbound calls to allowlisted services.<\/p>\n
\nIf a domain like *.amazonaws.com is allowlisted, a compromised workload can access attacker-controlled Amazon S3 buckets or Elastic Compute Cloud (EC2) instances.<\/p>\nReal-World Breach Examples<\/h4>\n
\n
\nDomain 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.<\/p>\n
\nThe 2024 VEILDrive<\/strong><\/a> 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.<\/li>\n
\nAmazon 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.<\/p>\nBest Practices to Strengthen Security<\/h4>\n
\n
Conclusion<\/h4>\n
Footnotes<\/h3>\n