Chave de API, AWS Secret ou Stripe Live Token comprometido co repositorio público de GitHub: raspado automatizado de bots en 60 segundos, rotación inmediata de claves e interruptor de facturación¶

No momento en que corres git push a un repositorio público de GitHub, GitLab ou Bitbucket (or temporarily flip a private repository to "Public" for even 10 seconds) mentres un ficheiro, .env configuración, notebook Jupyter (.ipynb), ou o historial de commit de Git anterior contén unha clave secreta activa (such as an AWS Access Key ID starting with AKIA, a Stripe Live Secret Key sk_live_, an OpenAI key sk-proj-, an Anthropic key sk-ant-, or a Google Cloud service account .json), unha rede global de bots automatizados de recollida de credenciais intercepta ese segredo en 2 a 60 segundos. Porque GitHub é público Events API, GH Archive, e as mangueiras contra incendios webhook en tempo real transmiten a todos os públicos PushEvent a nivel mundial, os robots de raspador maliciosos analizan a súa diferenza con expresións regulares e comezan a executar comandos automatizados na nube antes de que poida escribir git revert.

Dentro de 90 seconds dun AWS ou GCP segredo que chega a un repositorio público, as botnets automatizadas xeran instancias de GPU/CPU de tamaño máximo (such as p4d.24xlarge or c6i.32xlarge en rexións escuras como ap-east-1 Hong Kong, me-south-1 Bahrein ou sa-east-1 Sao Paulo) á mina Monero (XMR), solicite AWS Simple Email Service (SES) aumenta a cota para eliminar o spam de phishing ou clonar o teu privado S3 baldes e RDS bases de datos, xerando $5,000 to $80,000+ en facturas de computación en nube durante a noite. Do mesmo xeito, unha filtración OpenAI ou Anthropic A clave de API incorpórase inmediatamente a mercados subterráneos de LLM de "proxy inverso" que consumen miles de dólares en créditos simbólicos por minuto, mentres se filtra Stripe chave secreta activa (sk_live_...) concede aos atacantes acceso programático completo de lectura/escritura para emitir reembolsos fraudulentos, exportar clientes PII, ou activar pagos de Connect non autorizados. Se un atacante está a extorsionar activamente á súa organización despois de extraer as bases de datos de clientes coa súa clave filtrada, consulte as súas liñas directas de aplicación da lei e incidentes cibernéticos a través da nosa números de emerxencia directorio inmediatamente e revise as nosas guías relacionadas caída accidental da base de datos de produción, git force-push e clasificación de fugas secretas, caeu a base de datos de produción ou eliminouse o depósito S3 sen unha copia de seguridade recente, e seguridade do traballo remoto de emerxencia e privacidade dos datos.

Fai isto agora¶

1. ** NON perdas os teus primeiros 60 segundos correndo git rm .env ou git push --force: IR DIRECTAMENTE Á CONSOLA DO PROVEEDOR (AWS IAM, Stripe, OpenAI, GCP) E REVOCAR/DESACTIVAR A CHAV < 30 SECONDS.** Eliminando o ficheiro nun novo commit de Git (or even making the GitHub repository Private) non fai nada para deter os bots que xa rasparon a túa chave da mangueira de incendios de Eventos de GitHub hai 10 segundos. A chave en si debe ser eliminada na orixe primeiro.
2. Se un AWS chave (AKIA... ou ASIA...) filtrado: Aberto AWS IAM -> Users -> Security credentials e fai clic en Desactivar/Eliminar na clave de acceso inmediatamente e, a continuación, adxunta o AWSCompromisedKeyQuarantineV2 (or a blanketDenegar *inline policy) ao usuario de IAM e incremente a do usuario RevokeOldSessions política de matar a calquera temporal STS fichas que o atacante xa acuñou (see the exact STS bypass trap below).
3. ** Se a Stripe Clave secreta en directo (sk_live_... ou rk_live_...) filtrado:** Ir a dashboard.stripe.com/apikeys, fai clic ... -> Tecla Rolar e establece a caducidade da chave antiga en "Agora (Immediately)" (NOT "in 24 hours"). Comproba inmediatamente Stripe Dashboard -> Logs e Balance -> Payouts / Refunds para chamadas API non autorizadas.
4. Se un OpenAI, Anthropic, Google Gemini, ou SendGrid / Twilio chave filtrada: Elimina a clave API do panel de control do provedor inmediatamente e establece un Límite de gasto mensual duro ($0 ou o teu límite normal) na configuración de Facturación para cortar as solicitudes de streaming durante o voo.
5. Varrer TODAS as rexións de nubes (especially disabled/opt-in regions) para instancias fraudulentas de EC2, funcións Lambda, tarefas ECS, depósitos S3 e usuarios de IAM de porta traseira creados polo bot durante a xanela de exposición de 2 minutos. Os atacantes lanzan especificamente instancias de minería criptográfica en rexións nas que nunca fai clic na consola (like Stockholm eu-north-1, Osaka ap-northeast-3, or Mumbai ap-south-1) e cree un segundo usuario IAM oculto (or SSH key pair) para que poidan permanecer dentro da túa conta despois de que elimines a clave filtrada.
6. SÓ DESPOIS de revogar o segredo e eliminar as contas IAM de portas traseiras, elimine a confirmación de Git (using git-filter-repo) E póñase en contacto co soporte de GitHub (or remove cached PR/commit views) para purgar as cachés SHA de compromiso pendentes e, a continuación, envíe unha Solicitude de exención de facturación por fuga accidental de AWS/GCP se os bots realizaron unha factura masiva na nube.

Árbore de decisión: Resposta de emerxencia de 60 segundos por tipo secreto filtrado¶

Siga este diagrama de fluxo de contención de incidentes para eliminar a credencial comprometida, a persistencia do atacante e invertir a facturación desbocada na nube.

flowchart TD
    A["Segredo en directo comprometido co repositorio público de GitHub/GitLab (.env, código fonte ou historial de git)"] --> B["SEGUNDA 0 A 30: NON Executa git rm Primeiro. Abre a consola do provedor de API/Cloud e a chave REVOCA inmediatamente"]
    B --> C{"Que tipo de credencial en directo se expuxo?"}
    C -->|"1. Clave de acceso AWS (AKIA... / ASIA...)"| D["1. Desactivar/Eliminar a chave en IAM 2. Anexa a política de 'Denegar todo' en liña ao usuario (mata os tokens STS minted) 3. Auditar CloudTrail para usuarios de IAM de porta traseira"]
    C -->|"2. Chave secreta de Stripe Live (sk_live_... / rk_live_...)"| E["1. Tecla de rolo con caducidade = 'Inmediatamente' 2. Comproba /v1/refunds, /v1/transfers e puntos finales de webhook 3. Avalía a exposición de PII do cliente"]
    C -->|"3. OpenAI (sk-proj-...), Anthropic (sk-ant-...) ou Gemini Key"| F["1. Revogar a chave na Consola para programadores 2. Reducir o límite de facturación ríxido da organización a 0 USD temporalmente 3. Comprobar os rexistros de uso para verter tokens"]
    C -->|"4. URI de base de datos (postgres://, mongodb+srv://) ou URL de Redis"| G["1. Xire o contrasinal da base de datos inmediatamente 2. Execute pg_terminate_backend() / KILL para soltar conexións activas 3. Bloquear o grupo de seguranza só para as IP VPC"]
    D --> H["Executar varrido de computación multirexión (terminar Rogue EC2/EKS/SageMaker/Lambda nas máis de 30 rexións)"]
    E --> I["Limpar o historial de Git a través de 'git filter-repo' + Borrar vistas SHA de confirmación almacenadas en caché de GitHub"]
    F --> I
    G --> I
    H --> J{"Os bots automatizados acumularon unha factura na nube de 1.000 a 100.000 dólares ou máis?"}
    J -->|"SI"| K["Abrir un caso de asistencia de facturación de AWS/GCP -> Enviar unha auditoría de seguranza posterior á corrección + Solicitar unha soa vez fraude de cortesía/perdón de factura de filtración"]
    J -->|"NON"| I

Parte 1: Kill-Switch e Matriz Forense provedor por provedor (First 5 Minutes)¶

Use esta táboa de referencia para localizar o botón de revogación exacto, o comportamento automático de dixitalización secreta de GitHub e o vector de persistencia oculto para a súa credencial filtrada.

Parte 2: mergullo profundo: como expulsar a un atacante da túa conta de AWS (The 4-Step Cloud Eviction Protocol)¶

Porque filtrado AWS as credenciais teñen o maior radio de explosión financeira (up to $50,000+ per day in EC2/SageMaker/Bedrock bills), debes executar os catro pasos seguintes sempre que un AKIA... ou ASIA... a clave chega a un repositorio público:

+-----------------------------------------------------------------------------+
|     ANATOMY OF A 60-SECOND AUTOMATED AWS GITHUB SCRAPER BOT ATTACK          |
+-----------------------------------------------------------------------------+
|                                                                             |
|  [ SEC 00 ] Developer runs 'git push origin main' with .env (AKIA...)       |
|       |                                                                     |
|  [ SEC 04 ] Bot scrapes GitHub Events API Firehose -> Extracts AKIA key     |
|       |                                                                     |
|  [ SEC 06 ] Bot calls 'sts:GetCallerIdentity' & 'sts:GetSessionToken'       |
|       |     (Mints temporary ASIA... token that survives AKIA deletion.)    |
|       v                                                                     |
|  +----+------------------------------------------------------------------+  |
|  | [ SEC 15 TO 90: PARALLEL MULTI-REGION EXPLOITATION ]                  |  |
|  |  1. Persistence: Calls 'iam:CreateUser' / 'iam:CreateAccessKey'       |  |
|  |     (Creates hidden user 'aws-support-backup' with AdministratorAccess)|  |
|  |  2. Compute Abuse: Launches Auto-Scaling Groups of c6i.32xlarge /     |  |
|  |     g5.48xlarge in 12 regions + AWS Bedrock / SageMaker LLM endpoints |  |
|  |  3. Spam Abuse: Calls 'ses:PutAccountSendingAttributes' (50k emails)  |  |
|  |  4. Data Exfiltration: Lists & downloads S3 buckets / RDS snapshots   |  |
|  +-----------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------+

Paso 1: elimina ambos os estáticos AKIA Chave E todo acuñado ASIA Fichas de sesión¶

Eliminando o AKIA a clave da Consola de AWS non invalida temporalmente STS credenciais xa emitidas por sts:GetSessionToken. Para matar todo inmediatamente a través da AWS CLI (using a separate clean admin profile):

# 1. Delete the compromised Access Key immediately
aws iam delete-access-key --user-name CompromisedUser --access-key-id AKIAIOSFODNN7EXAMPLE

# 2. Attach an explicit 'Deny All' inline policy to the IAM User to immediately
#    invalidate any STS tokens minted by that user AND block all further actions:
aws iam put-user-policy --user-name CompromisedUser --policy-name EmergencyKillSwitch \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*"
    }]
  }'

Paso 2: Busca usuarios, roles e claves de acceso de Backdoor IAM en CloudTrail¶

Executa estes comandos da AWS CLI para comprobar se o bot creou un usuario IAM de porta traseira oculta ou anegou unha clave de acceso secundaria a unha das súas contas de empregado existentes durante a xanela:

# List all IAM users created recently across the account
aws iam list-users --query 'Users[?CreateDate>=`2026-10-30`].[UserName,CreateDate]' --output table

# Audit CloudTrail for every API call made by the compromised user in the last 24 hours
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=CompromisedUser \
  --max-results 50 \
  --query 'Events[].[EventTime,EventName,EventSource]' --output table

Paso 3: varrer todo 30+ Rexións de AWS para instancias Rogue EC2, grupos de escalado automático e traballos de Bedrock/SageMaker¶

Por que as vítimas aínda reciben a $12,000 factura a finais do mes despois de que "comprobasen o panel de control EC2 e viran cero instancias"? Porque a Consola de AWS só mostra unha rexión á vez (e.g., us-east-1), while the bot spun up 20 instances in ap-south-1 (Mumbai), eu-north-1 (Stockholm), e sa-east-1 (Sao Paulo), and hid them inside EC2 Auto Scaling Groups (ASGs) so that if you terminate the EC2 instance manually, the Auto Scaling Group launches a replacement 30 seconds máis tarde.

Run this multi-region bash one-liner to list all running or pending EC2 instances across every active AWS region in 10 seconds:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "=== Checking Region: $region ==="
  aws ec2 describe-instances --region "$region" \
    --filters "Name=instance-state-name,Values=running,pending,stopped" \
    --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,LaunchTime]' \
    --output table
done

Part 3: Scrubbing the Secret From Git History (git-filter-repo) & Purging GitHub's Hidden Commit Cache¶

Once the credential is dead at the provider level, you must remove the secret string from your repository's .git commit history so neither coworkers nor future scrapers can see it (and so GitHub's Push Protection stops blocking your branches).

1. Por que git rm .env + git commit Does NOT Remove the Secret From Git¶

Running git rm .env && git commit -m "remove env" only removes the file from the latest commit (HEAD); the plaintext secret remains permanently readable inside the parent commit (the parent commit) to anyone who clicks "Commits" on GitHub.

2. Rewrite the Repository History Cleanly Using git-filter-repo¶

1. If only the very last commit (HEAD) contained the secret (and nobody else has pulled it yet):

   # Remove the sensitive file from the staging index while keeping it on your local disk
   git rm --cached .env
   echo ".env" >> .gitignore
   git add .gitignore
   git commit --amend --no-edit
   git push --force-with-lease origin main
   

2. If the secret is buried several commits back in your history (or inside a code file you want to keep): Use git-filter-repo (the official, fast replacement recommended by Git and GitHub instead of the deprecated git filter-branch):

   # Option A: Completely purge a file (.env) from every commit in history
   git filter-repo --path .env --invert-paths --force
   
   # Option B: Replace a specific secret string with '***REMOVED***' across all files in history
   echo "sk_live_51NzExampleSecretKey12345==>***REMOVED***" > expressions.txt
   git filter-repo --replace-text expressions.txt --force
   
   # Force-push the rewritten history to GitHub across all branches and tags
   git push origin --force --all
   git push origin --force --tags
   

3. The Hidden GitHub Cache Trap (Dangling Commit SHAs)¶

Even after you run git filter-repo e git push --force, GitHub's web servers still keep the old, unreferenced ("dangling") commit SHA alive and publicly accessible at https://github.com/<owner>/<repo>/commit/<old-40-char-sha> (and in any forks or Pull Requests) until garbage collection runs. - How to Purge a Cached Commit SHA on GitHub Immediately: 1. Copy the full 40-character commit SHA of the leaked commit before you rewrote history. 2. Aberto https://support.github.com/contact -> ask to "Remove sensitive data / Clear cached views for a unreachable commit SHA" in repository owner/repo and provide the exact commit SHA (or use the GitHub Support portal's automated cache-purge workflow).

Part 4: How to Get a $5,000 to $100,000+ AWS or GCP Bot Bill Waived (The Courtesy Forgiveness Appeal)¶

What if you pushed an .env file on Friday afternoon, did not check your email until Monday morning, and woke up to a $28,400.00 AWS or Google Cloud bill from crypto-mining or LLM-proxy bots?

Non te asustes e NON canceles a túa tarxeta de crédito nin presentes un reembolso bancario aínda. Ambos Amazon Web Services (AWS) e Google Cloud Platform (GCP) dispoñen dunha Política de crédito de cortesía/axuste de facturación por fuga de credenciais por única vez por accidente interna establecida para desenvolvedores individuais, estudantes e startups, sempre que complete 100% da súa lista de verificación obrigatoria de corrección de seguridade antes que o seu equipo de revisión de facturación avalía a túa apelación.

Protocolo de exención de facturas de AWS/GCP en 5 pasos (90%+ Success Rate for First-Time Leaks)¶

1. Complete cada paso de corrección de seguridade primeiro (AWS Will Reject Your Waiver Until the Account Is Clean):
   • Eliminar a clave de acceso IAM comprometida (and the IAM User if possible).
   • Finalice todas as instancias EC2, Auto Scaling Group, volume EBS, Elastic IP, instancia RDS e S3 non autorizadas en todas as rexións (verify via AWS Cost Explorer and AWS Billing -> Bills -> Charges by Region that daily accrual has dropped back to $0.00).
   • Activar MFA de aplicación de hardware ou autenticador (Multi-Factor Authentication) na túa Conta raíz de AWS e en todos os usuarios de IAM.
2. Abre un caso de asistencia baixo "Account and Billing" (Free for All AWS/GCP Tiers, No Paid Support Plan Required):
   • Ir a console.aws.amazon.com/support/home -> Crear caso -> Conta e facturación -> Servizo: Facturación -> Categoría: Disputa un cargo/Conta comprometida.
3. Envíe este resumo exacto da corrección e das dificultades:
   • ** Recoñece a liña de tempo e a causa: ** Indique claramente cando a chave foi exposta accidentalmente en GitHub (e.g., "October 30 at 22:14 UTC") e cando foi revogada ("October 31 at 09:05 UTC").
   • Detalle os cargos non autorizados por rexión e servizo: enumera os importes exactos en dólares da actividade fraudulenta do bot en comparación coa túa factura mensual histórica normal (e.g., "My normal monthly AWS bill for the past 8 months is $14.50/month in us-east-1; the unauthorized charges total $18,420.12 across ap-east-1, eu-north-1, and sa-east-1 EC2/Bedrock usage").
   • Confirme o 100 % de corrección: Apunte con viñetas os pasos exactos que xa completou (1. Deleted IAM key AKIA...; 2. Terminated all unauthorized resources across all regions; 3. Audited CloudTrail for backdoor users; 4. Enabled Root & IAM MFA; 5. Configured AWS Budgets alerts).
   • Solicite educadamente un axuste único de facturación de cortesía: Explique que es un desenvolvedor individual/estudante/inicio en fase inicial, que paga un $18,420 A factura de bot non autorizada causaría graves dificultades económicas e pediría un crédito/exención de facturación por cortesía única polo uso fraudulento.
4. Cambie ou limite temporalmente a súa tarxeta de pago vinculada se a facturación automática é inminente:
   • Mentres o seu caso de AWS Billing Support está en proceso de revisión (which usually takes 5 to 15 business days mentres os equipos do servizo de facturación e seguridade de AWS verifican que todos os recursos fraudulentos están finalizados), póñase en contacto con AWS Support dentro do ticket e pídalles que coloquen unha retención temporal de facturación (defer auto-charge) na factura impugnada para que non descubra a súa conta bancaria mentres se procesa o axuste de crédito.

(Para incidentes relacionados coa seguridade dos desenvolvedores e do traballo remoto, consulte Caída accidental da base de datos de produción, git force-push, fuga secreta e triaxe de incidentes, Caeu a base de datos de produción ou eliminouse o depósito S3 sen unha copia de seguridade recente, Nómina confidencial, PII do cliente ou folla de cálculo HIPAA enviada accidentalmente por correo electrónico, e Seguridade do traballo remoto de emerxencia e privacidade dos datos.)

Autoridades rexionais de informes de violación de datos e seguridade na nube¶

Preguntas frecuentes¶

Se me decatara eu empurraba un .env arquivo a un repositorio público de GitHub e fixo o repositorio privado 2 minutos despois, aínda teño que xirar as miñas chaves?¶

Si, o 100 por cento das claves dese ficheiro deben considerarse comprometidas e revogadas inmediatamente. Os bots automatizados de recollida de credenciais non esperan a que Google indexe o teu repositorio; subscríbense directamente ao público en tempo real de GitHub `Events API` mangueira contra incendios (`and GH Archive`), que emite todos os públicos `PushEvent` globalmente dentro de 1 a 3 segundos de su `git push`. Cando fixo clic en "Configuración -> Cambiar visibilidade do repositorio -> Facer privado" dous minutos máis tarde, decenas de robots de raspador automáticos xa descargaran a súa diferenza de compromiso e puxeron en cola as súas credenciais de AWS, Stripe, OpenAI e base de datos para a súa explotación.

Por que os bots seguiron lanzando instancias EC2 na miña conta de AWS mesmo despois de que eliminei o filtrado AKIA clave de acceso?¶

Deleting a static `AKIA...` access key in AWS IAM only deactivates that specific permanent key; it does not invalidate temporary `ASIA...` Servizo de fichas de seguridade (`STS`) session tokens that the attacker already generated using `sts:GetSessionToken` ou `sts:AssumeRole` during the first few seconds after scraping your key (`which remain valid for up to 12 to 36 hours`). In addition, automated AWS attack scripts routinely call `iam:CreateUser` e `iam:CreateAccessKey` in their very first second of access to plant a second, hidden backdoor administrator account. To stop an active AWS intrusion completely, you must delete the `AKIA` key, attach an explicit `Deny *` inline policy to the compromised IAM user (`which immediately invalidates all minted STS tokens`), and audit CloudTrail for any newly created IAM users or roles.

Will AWS or Google Cloud forgive a massive $10,000+ factura se os piratas informáticos roubaron a miña chave da API de GitHub e minaron criptomonedas?¶

Na gran maioría das fugas accidentais por primeira vez, si, sempre que actúe rapidamente, coopere plenamente co seu equipo de seguridade e non ignore a factura. Tanto AWS como Google Cloud teñen unha política interna de axuste de facturación de cortesía única para desenvolvedores e pequenas empresas afectadas por picos de fugas de credenciais non autorizadas. Antes de solicitar a exención de facturas na compatibilidade con "Conta e facturación", primeiro debes demostrar que a filtración está pechada ao 100 %: revoga as claves IAM expostas, finaliza todas as instancias informáticas fraudulentas e os grupos de Auto Scaling nas máis de 30 rexións globais, activa a autenticación multifactorial (`MFA`) na súa conta raíz e configure alertas de custos de AWS Budgets.

Por que fai git rm .env non eliminar a miña chave secreta de GitHub?¶

Git é un rexistro inmutable de control de versións: cando executas `git rm .env` e presione unha nova confirmación, Git só rexistra que o ficheiro está ausente na instantánea máis recente (`HEAD`), mantendo o contido en texto plano completo de `.env` almacenado permanentemente dentro do commit anterior (`the parent commit`) no historial de commit do seu repositorio. Aínda que reescribas a túa historia con `git filter-repo` e forzar, calquera pode aínda ler o segredo se non o revogou na consola do provedor. Sempre revogue e xire primeiro a chave secreta no panel de control do seu provedor de nube e, a continuación, utilízaa `git filter-repo` para eliminar a cadea morta do teu historial de commit.

Guías relacionadas¶

• Caída accidental da base de datos de produción, git force-push, fuga secreta e triaxe de incidentes
• Caeu a base de datos de produción ou eliminouse o depósito S3 sen unha copia de seguridade recente
• Nómina confidencial, PII do cliente ou folla de cálculo HIPAA enviada accidentalmente por correo electrónico ao destinatario incorrecto
• Cota de pantalla accidental da folla de salario confidencial, xestor de contrasinais ou lista de despedimentos en Zoom/Teams
• Seguridade do traballo remoto de emerxencia e privacidade dos datos
• Números de emerxencia

Fontes e orientacións oficiais¶

• ** Servizos web de Amazon (AWS Security Incident Response Guide & AWS Knowledge Center: "What should I do if I notice unauthorized activity or exposed IAM access keys?"):** AWSCompromisedKeyQuarantineV2 Comportamento da política, invalidación da temporalidade STS Fichas de sesión (RevokeOldSessions) e Auditoría de recursos multirrexional.
• ** Documentación de GitHub (GitHub Secret Scanning, Push Protection, & "Removing sensitive data from a repository" using git-filter-repo):** Programa de revogación automática de socios (Stripe, AWS, OpenAI, NPM), git-filter-repo Reescritura do historial e eliminación de SHA de compromiso en caché inalcanzables.
• Stripe Inc. (Stripe Developer Security Guide: API Key Rotation & Compromised Key Incident Triage): Inmediato sk_live_ Caducidade da clave, Auditoría /v1/events e /v1/webhook_endpoints, e claves de restrición mediante rk_live_ Ámbitos.
• NIST (Special Publication 800-61 Rev. 2 / Rev. 3: Computer Security Incident Handling Guide) & OWASP (Secrets Management Cheat Sheet): Contención de credenciais, Federación de identidades de carga de traballo OIDC efímera (replacing static CI/CD keys), e Escaneo secreto previo ao compromiso.