AWS Signer Burp Suite Extension

The AWS Signer Burp Suite extension re-signs AWS Signature Version 4 (SigV4) requests as they pass through Burp, using credential profiles you configure in the extension’s tab. It is the standard way to tamper with AWS API traffic interactively: modify the request in Repeater/Proxy, and the extension fixes up the signature that would otherwise break.

How it decides to sign

Per the project’s README, the extension inspects every request passing through Burp and re-signs it if both the X-Amz-Date and Authorization headers are present, updating those headers with the configured profile’s credentials. Profiles can be static keys, assume-role chains, or command-sourced credentials, and can be imported automatically from AWS CLI credential files, environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN), or the clipboard. An “Always Sign With” global setting forces one profile for all requests; otherwise the extension matches on the request’s existing key ID.

A SigV4 request the extension will update looks like:

GET /?Param1=value1 HTTP/1.1
Host: example.amazonaws.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
X-Amz-Date: 20150830T123600Z
Authorization: AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20190101/us-west-1/test/request, SignedHeaders=content-type;host;x-amz-date, Signature=e3b0c442...

The trick: placeholder headers are enough

Because the extension only checks for the presence of the signing headers (not their validity), you can bootstrap signing onto an arbitrary hand-written request by pasting in well-formed dummy headers — no need to capture a real CLI request first:

X-Amz-Content-Sha256: 00000000
X-Amz-Date: 00000000T000000Z
Authorization: AWS4-HMAC-SHA256 Credential=.../.../.../.../request, SignedHeaders=Host;X-Amz-Content-Sha256;X-Amz-Date, Signature=00000000

The extension sees the headers, re-computes the real SigV4 signature over your modified request with the profile’s credentials, and overwrites them. This makes it practical to hand-craft calls to any AWS endpoint directly in Repeater.

Background: what SigV4 signs

AWS SigV4 signing (per the IAM documentation) is a three-step process: build a canonical request (method, URI-encoded path, query string, signed headers, payload SHA-256 hash), derive a string to sign, then compute an HMAC-SHA256 signature with a key derived from secret + date + region + service, and attach it in the Authorization header. AWS replicates the computation server-side to verify. Temporary (STS) credentials additionally require the X-Amz-Security-Token header. Because the signature covers the request contents, any manual edit invalidates it — hence the need for a re-signing extension when proxying.

Workflow context

• Pair with burp-suite-aws-cli-proxy to harvest real signed requests from the AWS CLI as seed material (or skip that step entirely with the placeholder trick above).
• Signed, mutated requests are the foundation of aws-sigv4-api-flooding-style API abuse and of the reconnaissance calls in aws-root-account-email-discovery.
• Temporary credentials to load into a profile can come from instance metadata — see ec2-instance-metadata-imds.

Sources

• PortSwigger/aws-signer — Burp Extension for AWS SigV4 Signing
• Create a signed AWS API request — SigV4
• Amazon S3 API Reference — SigV4 Authenticating Requests

See also

• burp-suite — the host platform
• json-web-tokens — another token-in-header authentication scheme commonly tested through Burp