AWS signup/login: TM captcha auto-solve, OTP, payment resume, IdC gating

Verified end-to-end on signin.aws.amazon.com + signup.aws.amazon.com (root login → console → payment form). CDP endpoint on a locally-launched Chrome (http://127.0.0.1:<port>/json/list), raw websocket CDP (no Playwright needed).

1. Threat-mitigation text captcha (WORKING auto-solve)

The "Making sure it's you" challenge lives in an iframe; input is captchaGuess.

Loop recipe:

Track the iframe's live execution context (contexts get reused IDs after reload — keep an ordered list of live contexts, pick the newest containing captchaGuess).
If no captcha visible: click the main-page Verify button (match by innerText), then poll for captchaGuess visible (~2.5s).
If captcha already open for a while: click Reset INSIDE the iframe to force a fresh image.
Get the image WITHOUT screenshot cropping: read img.src from the iframe DOM (Array.from(document.querySelectorAll('img')).filter(im => im.src.startsWith('http') && im.width > 50), take last), then download the S3 URL with plain urllib outside the browser. Screenshot-crop and Network.getResponseBody both race the challenge TTL; DOM img-src + direct download is the fast reliable path. EXCEPTION — Builder ID platform/d- login pages: the S3 img.src is single-use (403 on outside refetch) and Reset emits NO Network events on the iframe target; there capture via main-target Page.captureScreenshot with clip = iframe rect (main doc) + inner img rect (iframe doc) instead — the iframe is a separate CDP target.
OCR with a local VL model — qwen3-vl-plus via the dashscope proxy reads these in ~4s (qwen-vl-ocr was 18s and less accurate).
Fill answer via native value setter + input/change events, then JS form.submit()/button click. Real keystrokes (Input.dispatchKeyEvent) fail on this form (typed: None) and lose the TTL race — do not use them.
Wrong answer rotates the challenge silently — no error message. Treat submit as loop step: after submit wait, if a new captcha appears go to 3.

One round (reset → img dl → OCR → submit) ≈ 7s; a few rounds per login is normal.

Sign-in page: pick "root user" email path by clicking the actual element (a, button, [role=link] containing the root-email text), not by body-text heuristic.
After captcha+password, error "An AWS account with that sign-in information does not exist" means the email is an AWS Builder ID, not an account root user. Builder ID ≠ AWS account — signin with it will never reach a console. Use the email the account was actually registered with.

3. Email OTP + MFA skip

"Confirm you're you" page: 6-digit code to account email. For t-online pool: imaplib.IMAP4_SSL('secureimap.t-online.de', 993), scan last ~15 mails (full-inbox SEARCH ALL chokes on 18k+ mailboxes — fetch last N ids instead), regex (?:Verification code|code)[^\d]{0,20}(\d{6}) on AWS/Amazon mails.
Fill code with JS native setter, click Verify and continue.
Next page is MFA registration ("required in N days") — click Skip for now → lands in console.
Save state (stage=console_logged_in) immediately; the session cookies persist in the browser profile.

4. CDP quirks on AWS pages

Runtime.evaluate on console.aws.amazon.com can hang >90s (heavy SPA renderer). Don't fight it: open a NEW tab via PUT /json/new?<url>, or navigate a light tab (signup.aws) and let redirects settle, then read state from a fresh /json/list.
After login, navigating the same tab to a console URL is safer than forcing Page.navigate mid-session (session bounce resets to signin).

5. Payment resume for stuck (incomplete) accounts

Stuck account → https://signup.aws.amazon.com/billing/signup/incomplete → link "Complete your AWS registration" → signup?type=resubscribe#/paymentinformation (contact/plan steps are skipped, already stored).
Card form is React/awsui: fill with native value setter + input/change (card number field masks to 4147 2046 ... — that's normal). Expiry as MM/YY.
Click Continue, then watch network: aws-payment-encryption-prod.../createpaymentinstrument 200 = card encrypted OK; aws-payments-gateway-service.../PaymentInstrument is the actual verdict. Page shows Error 880104 alert on rejection.

6. Error 880104 semantics (hard-won)

880104 = the payment instrument is rejected at the real $1 pre-auth. Two distinct failing classes: (a) generated/fake VCCs — always, any BIN; (b) genuinely-issued cards from blacklisted issuer families — Monobank/UA BINs (444111 etc.) are blanket-blocked regardless of account age, proxy, or billing address (multiple real cards on fresh accounts + DE-resi + DE billing: encrypt/createpaymentinstrument 200, gateway verdict 880104).
Not engineerable via proxy/address/account rotation — do not burn resources retrying. What passes: EU-issued card (Revolut/Wise-class BIN) or a live no-KYC crypto VCC with real 3DS/authorization capability (kliencard-class; Luhn-generated cards are useless — AWS does a live authorization hold).
Distinguish from UpCloud/Braintree: there a $0 auth geo-blocks all UA BINs; AWS rejects both non-existent cards AND banned issuer families.

7. IAM Identity Center gating

console.aws.amazon.com/singlesignon on an account with incomplete signup redirects to signup/incomplete — IdC instance cannot be enabled until payment completes. Anything downstream (Kiro via IdC, region us-east-1/eu-central-1) is blocked. Sequence is always: payment → IdC → app SSO.
When enabling IdC: use "Enable an account instance", never "Enable with AWS Organizations" (org creation has different requirements/limits).

5.7 KiB Raw Blame History