By continuing to use the site or forum, you agree to the use of cookies, find out more by reading our GDPR policy

A newly discovered technique by a researcher shows how Google's App Engine domains can be abused to deliver phishing and malware while remaining undetected by leading enterprise security products. Google App Engine is a cloud-based service platform for developing and hosting web apps on Google's servers. While reports of phishing campaigns leveraging enterprise cloud domains are nothing new, what makes Google App Engine infrastructure risky in how the subdomains get generated and paths are routed. Typically scammers use cloud services to create a malicious app that gets assigned a subdomain. They then host phishing pages there. Or they may use the app as a command-and-control (C2) server to deliver malware payload. But the URL structures are usually generated in a manner that makes them easy to monitor and block using enterprise security products, should there be a need. Therefore, a cybersecurity professional could block traffic to and from this particular app by simply blocking requests to and from this subdomain. This wouldn't prevent communication with the rest of the Microsoft Azure apps that use other subdomains. It gets a bit more complicated, however, in the case of Google App Engine. Security researcher Marcel Afrahim demonstrated an intended design of Google App Engine's subdomain generator, which can be abused to use the app infrastructure for malicious purposes, all while remaining undetected. A subdomain, in this case, does not only represent an app, it represents an app's version, the service name, project ID, and region ID fields. But the most important point to note here is, if any of those fields are incorrect, Google App Engine won't show a 404 Not Found page, but instead show the app's "default" page (a concept referred to as soft routing). "Requests are received by any version that is configured for traffic in the targeted service. If the service that you are targeting does not exist, the request gets Soft Routed," states Afrahim, adding: "If a request matches the PROJECT_ID.REGION_ID.r.appspot.com portion of the hostname, but includes a service, version, or instance name that does not exist, then the request is routed to the default service, which is essentially your default hostname of the app." Essentially, this means there are a lot of permutations of subdomains to get to the attacker's malicious app. As long as every subdomain has a valid "project_ID" field, invalid variations of other fields can be used at the attacker's discretion to generate a long list of subdomains, which all lead to the same app. The fact that a single malicious app is now represented by multiple permutations of its subdomains makes it hard for sysadmins and security professionals to block malicious activity. But further, to a technologically unsavvy user, all of these subdomains would appear to be a "secure site." After all, the appspot.com domain and all its subdomains come with the seal of "Google Trust Services" in their SSL certificates. Even further, most enterprise security solutions such as Symantec WebPulse web filter automatically allow traffic to trusted category sites. And Google's appspot.com domain, due to its reputation and legitimate corporate use cases, earns an "Office/Business Applications" tag, skipping the scrutiny of web proxies. This complete article is posted on OUR FORUM with much more information.