What to redact in a cloud console screenshot

Cloud console screenshots are the densest evidence most security reports contain. A single AWS console frame can carry an account ID, half a dozen ARNs, a bucket name, an IAM role, a region, a VPC ID and the account alias in the top-right menu — before you have even looked at the finding you meant to capture.

Most of those identifiers are not secrets in the sense a password is. They are worse in a specific way: they are durable. A password gets rotated. An AWS account ID is permanent.

Why identifiers matter more than they look

The instinct is to redact things that look like credentials and leave the rest, on the grounds that an account number is not a key. That reasoning breaks down for three reasons.

Some namespaces are global. An S3 bucket name is unique across all of AWS. Publishing one confirms that exact bucket exists and belongs to someone — and organisations name buckets after themselves, their clients and their environments.
Some identifiers are valid principals. A GCP service account address is a real, addressable identity. An AWS account ID is the thing trust policies are written against.
They compose. Account ID plus role name plus region is enough to describe a target precisely, and identifiers that are individually dull become a map when collected across a report.

None of this means an account ID is catastrophic on its own. It means the default should be to remove it, and keeping it should be a decision rather than an oversight.

What to look for, by provider

AWS

Account ID — twelve digits. Appears in the top-right account menu, in every ARN, in IAM screens and in CloudTrail entries.
Account alias — usually the organisation or environment name, shown wherever the account ID is.
ARNs — these embed the account ID, the region, the service and the resource name in one string. Redacting an ARN by covering only the tail leaves the account ID in the middle of it.
Access key IDs beginning AKIA or ASIA, and anything that looks like a secret access key.
Bucket names, IAM user and role names, VPC, subnet and instance IDs.

Azure

Subscription ID and tenant ID — both GUIDs, both effectively permanent, both shown constantly in the portal.
Resource group and storage account names. Storage account names share the global-namespace property that bucket names have.
The signed-in user, shown in the top-right, which is usually a real work address.

Google Cloud

Project ID and project number. The project ID is globally unique and chosen by a human, so it is frequently the company name.
Service account addresses, which look like email addresses and are valid identities.
The project picker at the top of the console, which lists other projects you have access to — often the single most revealing element in the frame.

What a tool catches, and what it will not

This is worth being precise about, because the failure mode of automatic detection is trusting it.

Blackbar's detectors reliably find things with distinctive shape: AWS access keys and secret keys, private key blocks, JWTs, authorisation headers, Slack, GitHub, Stripe and Google API keys, connection strings, IP addresses, MAC addresses, hostnames, email addresses and UUIDs. That last one matters here — Azure subscription and tenant IDs are GUIDs, so they get caught as a matter of form.

An AWS account ID has no shape. It is twelve digits. There is no prefix, no checksum, no separator that distinguishes it from an order number, a timestamp or a phone number fragment. No detector can identify one reliably from a screenshot without guessing, and a detector that guessed would flood every capture with false positives. The same is true of bucket names, resource group names and GCP project IDs: they are arbitrary strings a human chose.

Those you draw yourself. Automatic detection is there to catch what you would miss, not to replace the pass where you decide what matters.

The console chrome

The finding is in the middle of the frame. The leaks are usually at the edges:

The account menu, top right — account alias, account ID, signed-in identity.
The region selector, which tells anyone reading where to look.
Breadcrumbs and the resource path above the panel you cared about.
Browser tabs, showing which other consoles, tickets and internal tools are open.
Notification toasts that arrived mid-capture, which frequently name unrelated resources.

Two habits remove most of this: capture the panel rather than the window, and use a browser profile that has no other tabs, no bookmarks bar and no extensions. If you do capture the full window, a one-click strip over the browser chrome and the account menu is faster and more reliable than remembering each element.

Keep it readable across the report

A finding that spans six screenshots becomes unreadable if the same account is a black bar in each one, because the reader cannot tell whether they are looking at the same account twice or two different accounts. Consistent pseudonyms fix this: the same value gets the same label everywhere, so [ACCT-1] in screenshot two is provably the same account as [ACCT-1] in screenshot five, and the reader can follow the finding without ever seeing the real value.

Keep the mapping. Your client will ask which account [ACCT-1] was, and the answer belongs in an encrypted note beside the engagement, not in the deliverable.

Verify before it leaves

Redaction that has not been checked is a belief, not a control. The checks are cheap:

strings evidence.png | grep -E "[0-9]{12}"     # bare account IDs
strings evidence.png | grep -iE "arn:aws|\.s3\.|blob\.core|googleapis"
exiftool evidence.png | head -40               # what the container carries

If the account ID comes back out of the file you just redacted, the bar you drew is sitting on top of live text rather than replacing it — which is the difference between a redaction and a drawing. That distinction, and why it catches so many people, is the subject of blur and pixelation are not redaction.