Blob Is S3 Is Cloud Storage: The Cloud Name Map for Pentesters

The client says "our files are in Blob" and you're thinking "S3". It's the same thing. AWS, Azure and Google Cloud all sell the same building blocks, they just give them different names.

This cheat sheet maps the names across all three, then draws the line that trips people up when scoping: Azure and Google Cloud are the infrastructure, Microsoft 365 and Google Workspace are the office suites, and they share identity underneath. Keep it open on your next scoping call. It'll save you a few awkward pauses. It's the first post in the Cloud Journey.

AWS, Azure and Google Cloud service names side by side

Read across a row and you've got the same service in each cloud. Know one column and you'll find your way round the other two.

A few terms, in case they're new to you. PaaS (platform as a service) means you hand over your code and the provider runs the servers. A serverless function is a small piece of code that only runs when something triggers it, like an HTTP request or a file landing in a bucket. Object storage keeps files as objects in a bucket (AWS, Google) or a container (Azure), and you reach them over HTTPS on port 443 instead of mounting them like a drive.

If a client runs EKS, AKS or GKE, the cluster half of the test is Kubernetes, and the Kubernetes Journey covers it. The 4Cs of cloud native security shows where the cloud layer sits under the cluster.

The cloud names a tester needs most

The table above is what clients talk about. This one's what you'll spend a test inside: who can do what, where the secrets live and what gets logged. You'll type these three CLI names more than any other.

Here's your first look at storage in each cloud, once you've been given credentials that are in scope:

aws s3 ls
az storage account list -o table
gcloud storage buckets list

Each one lists the buckets or storage accounts your identity can see. If you get an empty list, don't assume there's no storage. It only means your identity can't see any, and that tells you something about its access. Least privilege on cloud IAM is the theme of the IAM and host firewall post.

Cloud platform vs office suite: Azure, M365, GCP, Workspace

This is the mix-up you'll hit most when scoping. Azure and Microsoft 365 both sit on Entra ID (it was called Azure AD until July 2023), but you test them very differently. The same goes for Google Cloud and Google Workspace (it was G Suite until 2020). Two products, one login.

• Azure is infrastructure: VMs, VNets, storage accounts, identity and security services.
• Microsoft 365 is the office side: Outlook, Teams, SharePoint, OneDrive and the Office apps.
• Google Cloud is infrastructure: Compute Engine, VPC networks, Cloud Storage, databases and AI.
• Google Workspace is the office side: Gmail, Drive, Docs, Sheets and Calendar.

Shared identity: why one side leads to the other

Azure and M365 share one Entra ID tenant: the same users, groups and Conditional Access rules. That's why a weak M365 user can often be your way into Azure. By default, any member user can read the directory's users and groups, and that same account may hold an Azure role nobody remembers granting. So you'll want to check how the tenant's set up even if only one side is in scope.

Google has the same link. Workspace and Google Cloud sit on the same Cloud Identity. A Workspace super admin can grant the Organization Administrator role (roles/resourcemanager.organizationAdmin) on the Google Cloud organisation, which covers every project under it. Google's own guidance says to keep super admin accounts out of day-to-day cloud admin, and that's why.

You can tell which suite a client uses before they've given you any access. Their DNS mail (MX) records give it away:

dig +short MX example.com

For a Microsoft client, the tenant itself is public too. Ask for the domain's OpenID configuration and you'll find the tenant ID, a 36-character GUID, inside the issuer:

curl -s https://login.microsoftonline.com/example.com/v2.0/.well-known/openid-configuration | jq -r .issuer

Expect https://login.microsoftonline.com/<tenant-guid>/v2.0. Get an error instead? Then the domain has no Entra tenant. Next, check whether Microsoft handles sign-in or passes it to the client's own identity provider:

curl -s "https://login.microsoftonline.com/getuserrealm.srf?login=user@example.com&xml=1"

Look for one tag, <NameSpaceType>. Managed means passwords are checked by Entra ID. Federated means sign-in is handed to something like ADFS or Okta, which is then part of the attack surface.

Check whether an M365 user reaches Azure

If the client gives you a test M365 account, these three commands show you how far it reaches into the Azure side of the same tenant:

az login --allow-no-subscriptions
az account list -o table
az ad user list --query "length(@)"

--allow-no-subscriptions lets you sign in even when the user has no Azure subscription access. Without it, az login can stop with an error. az account list then shows any subscriptions the user can reach, and az ad user list counts the users the account can read from the directory. If a plain office user can list every user in the tenant, or turns up with a subscription, that's your first lead.

On the Google side, you'd check whether a Workspace admin account can see the Google Cloud organisation and its IAM policy:

gcloud organizations list
gcloud organizations get-iam-policy ORG_ID

Common mistakes

Scoping "Microsoft" as one thing. An M365 tenant review and an Azure config review need different access, tools and time. Write them as separate lines in your scope. Then note the shared Entra ID tenant on both, because whoever tests one side will end up looking at the identity that the other side depends on too.

Treating an empty storage list as "no storage". aws s3 ls only shows what your identity can list. Ask which AWS accounts, Azure subscriptions or GCP projects are in scope, and make sure you're testing with the right role.

Using old names in a report. Azure AD is Entra ID, G Suite is Workspace and Cloud Functions are Cloud Run functions. Old names make your report look dated, and they'll confuse the reader.

Forgetting the CDN and file shares. CloudFront, Front Door, EFS and Azure Files rarely come up in the client's summary. Ask anyway. A CDN or file share nobody mentioned is still part of the estate.

Fix it, and detect it

If you're defending, the shared identity is the thing to fix. In Entra ID, set allowedToReadOtherUsers to false in the default user permissions so ordinary users can't read the whole directory. Review who holds Azure roles every quarter. Give admins a separate account for cloud work. On the Google side, keep super admins to two or three named accounts, each on a hardware security key, and out of daily Google Cloud admin.

To spot the checks above, watch the audit logs from the second table. In CloudTrail, it's ListBuckets calls. In Entra sign-in logs, it's an office user signing in to the Microsoft Azure CLI app for the first time. In Cloud Audit Logs, it's GetIamPolicy on the organisation. The Cloud pentest notes collect every command here as a check.

Quick recap

• S3, Blob Storage and Cloud Storage are one job with three names, and the same goes for every row in the map.
• Azure and Google Cloud are infrastructure. M365 and Workspace are office suites. Scope and test them separately.
• Azure and M365 share one Entra ID tenant, and Workspace and Google Cloud share Cloud Identity, so one side can lead to the other.
• MX records and the Entra OpenID configuration tell you a client's suite and tenant ID with no login.

Try it yourself

Pick three companies you know and run dig +short MX on their domains. For each Microsoft one, pull the tenant ID and check whether it's managed or federated. Then write down which column of the platform table you'd expect to test for each.

If you're testing cloud and office tenants and have a scoping question that always catches clients out, I'd like to hear it. Send it my way on LinkedIn.

References

• Google Cloud: super administrator account best practices - super admins and the Organization Administrator role.

FAQ

What is the Azure equivalent of AWS S3?

Azure Blob Storage is the equivalent of Amazon S3, and Google Cloud Storage is the GCP version. All three store files as objects in containers or buckets, reachable over HTTPS. For archive data, S3 Glacier maps to the Blob Archive tier in Azure and the Archive storage class in Google Cloud Storage.

Is Microsoft 365 part of Azure?

No. Microsoft 365 is the productivity suite (Outlook, Teams, SharePoint, OneDrive) and Azure is the infrastructure platform (VMs, networks, storage). They do share one Entra ID tenant, so the same users, groups and sign-in policies apply to both, which is why a test of one often touches the other.

How do you find a company's Microsoft tenant ID?

Request the OpenID configuration for their domain from login.microsoftonline.com. The issuer field in the reply contains the tenant ID, a GUID. It needs no login, and it also confirms the company has a Microsoft Entra tenant at all, which tells you M365 or Azure is in play.

Related reading

• Least Privilege, Two Ways: Cloud IAM and a Host Firewall (cloud IAM roles in practice)
• The 4Cs of Cloud Native Security, and a Real Attack Chain (where cloud sits under the cluster)
• Browse the whole Cloud Journey