API Key, AWS Secret або Stripe Live Token, призначені для загальнодоступного GitHub Repo: автоматичне сканування роботом за 60 секунд, миттєва ротація ключа та Billing Kill-Switch¶

У той момент, коли ви біжите git push у публічний репозиторій GitHub, GitLab або Bitbucket (or temporarily flip a private repository to "Public" for even 10 seconds) поки файл, .env конфігурація, ноутбук Jupyter (.ipynb), або старіша історія комітів Git містить активний секретний ключ (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), глобальна мережа автоматизованих ботів, які збирають облікові дані, перехоплює цей секрет за від 2 до 60 секунд. Оскільки GitHub публічний Events API, GH Archive, а пожежні шланги в режимі реального часу транслюють кожну публіку PushEvent у всьому світі шкідливі боти-збирачі аналізують вашу різницю за допомогою регулярних виразів і починають виконувати автоматизовані хмарні команди ще до того, як ви зможете ввести git revert.

Протягом 90 seconds ан AWS або GCP секрет, потрапляючи в загальнодоступне репо, автоматизовані ботнети запускають екземпляри GPU/CPU максимального розміру (such as p4d.24xlarge or c6i.32xlarge через незрозумілі регіони, як ap-east-1 Гонконг, me-south-1 Бахрейн, або sa-east-1 Sao Paulo) для видобутку Monero (XMR), запитайте AWS Simple Email Service (SES) збільшується квота, щоб видаляти фішинговий спам або клонувати ваш особистий S3 відра і RDS баз даних, що генерують $5,000 to $80,000+ у рахунках за хмарні обчислення за ніч. Аналогічно, витік OpenAI або Anthropic Ключ API негайно додається до підпільних торгових майданчиків LLM із «зворотним проксі», які витрачають тисячі доларів кредитів токенів за хвилину, у той час як витік Stripe живий секретний ключ (sk_live_...) надає зловмисникам повний програмний доступ для читання/запису, щоб здійснювати шахрайські відшкодування, експортувати клієнта PIIабо ініціювати неавторизовані виплати Connect. Якщо зловмисник активно здирує вашу організацію після того, як викрав бази даних клієнтів за допомогою вашого витоку ключа, зверніться до місцевих правоохоронних органів і гарячих ліній щодо кіберінцидентів за допомогою нашої номери екстрених служб негайно перегляньте наші пов’язані посібники випадкове падіння робочої бази даних, git force-push і сортування секретних витоків, робочу базу даних видалено або сегмент S3 видалено без останнього резервного копіювання, і надзвичайна безпека віддаленої роботи та конфіденційність даних.

Зробіть це зараз¶

1. НЕ витрачайте свої перші 60 секунд на пробіжку git rm .env або git push --force: ПЕРЕЙТИ ПРЯМО ДО КОНСОЛІ ПОСТАЧАЛЬНИКА (AWS IAM, Stripe, OpenAI, GCP) ТА СКАСУВАТИ/ДЕАКТИВУВАТИ КЛЮЧ IN < 30 SECONDS. Видалення файлу в новому коміті Git (or even making the GitHub repository Private) нічого не зупиняє ботів, які вже 10 секунд тому витягли ваш ключ із пожежного шланга GitHub Events. Сам ключ потрібно спочатку вбити в джерелі.
2. Якщо ан AWS ключ (AKIA... або ASIA...) витік: Відкрито AWS IAM -> Users -> Security credentials і негайно натисніть Деактивувати/Видалити на ключі доступу, а потім прикріпіть AWSCompromisedKeyQuarantineV2 (or a blanketЗаперечувати *inline policy) користувачеві IAM і збільшити значення користувача RevokeOldSessions політики, щоб убити будь-який тимчасовий STS токени, які зловмисник уже викарбував (see the exact STS bypass trap below).
3. Якщо a Stripe Секретний ключ Live (sk_live_... або rk_live_...) витік: Перейти до dashboard.stripe.com/apikeys, натисніть ... -> Перекинути ключ і встановити термін дії старого ключа на "Зараз (Immediately)" (NOT "in 24 hours"). Негайно перевірте Stripe Dashboard -> Logs і Balance -> Payouts / Refunds для неавторизованих викликів API.
4. Якщо ан OpenAI, Anthropic, Google Gemini, або SendGrid / Twilio витік ключа: Негайно видаліть ключ API на інформаційній панелі постачальника та встановіть Жорсткий місячний ліміт витрат ($0 або ваш звичайний ліміт) у налаштуваннях платежів, щоб відключити запити потокового передавання під час польоту.
5. Очистити ВСІ хмарні регіони (especially disabled/opt-in regions) для підроблених екземплярів EC2, функцій Lambda, завдань ECS, сегментів S3 і бекдор-користувачів IAM, створених ботом протягом 2-хвилинного вікна експозиції. Зловмисники спеціально запускають екземпляри криптомайнінгу в регіонах, які ви ніколи не натискаєте на консолі (like Stockholm eu-north-1, Osaka ap-northeast-3, or Mumbai ap-south-1) і створіть другого прихованого користувача IAM (or SSH key pair), щоб вони могли залишитися у вашому обліковому записі після видалення витоку ключа.
6. Тільки ПІСЛЯ того, як секрет буде відкликано та бекдор-рахунки IAM очищено, видаліть комміт із Git (using git-filter-repo) І зверніться до служби підтримки GitHub (or remove cached PR/commit views), щоб очистити завислі кеші SHA, а потім надіслати Запит на відмову від виставлення рахунків у зв’язку з випадковим витоком AWS / GCP, якщо боти виставили величезний рахунок за хмару.

Дерево рішень: 60-секундне екстрене реагування за типом витоку секрету¶

Follow this incident containment flowchart to kill the compromised credential, sever attacker persistence, and reverse runaway cloud billing.

flowchart TD
    A["Live Secret Committed to Public GitHub / GitLab Repo (.env, вихідний код або історія git)"] --> B["ДРУГИЙ ВІД 0 ДО 30: НЕ запускайте git rm спочатку. Відкрийте консоль Cloud/API Provider Console і негайно СКАСУЙТЕ ключ"]
    B --> C{"Який тип активних облікових даних було розкрито?"}
    C -->|"1. AWS Access Key (AKIA... / ASIA...)"| D["1. Деактивуйте/видаліть ключ у IAM 2. Додайте вбудовану політику «Заборонити все» до користувача (знищує карбовані токени STS) 3. Аудит CloudTrail для бекдор-користувачів IAM"]
    C -->|"2. Секретний ключ Stripe Live (sk_live_... / rk_live_...)"| E["1. Roll Key із закінченням терміну дії = «Негайно» 2. Перевірте /v1/refunds, /v1/transfers & кінцеві точки Webhook 3. Оцініть вплив ідентифікаційної інформації клієнта"]
    C -->|"3. OpenAI (sk-proj-...), Anthropic (sk-ant-...) або Gemini Key"| F["1. Відкликайте ключ у Консолі розробника 2. Тимчасово знизите межу жорсткого виставлення рахунків організації до 0 доларів США 3. Перевірте журнали використання на наявність маркерів."]
    C -->|"4. URI бази даних (postgres://, mongodb+srv://) або URL-адреса Redis"| G["1. Негайно змініть пароль БД 2. Запустіть pg_terminate_backend() / KILL, щоб скинути активні підключення 3. Заблокуйте групу безпеки лише для IP-адрес VPC"]
    D --> H["Run Multi-Region Compute Sweep (Terminate Rogue EC2/EKS/SageMaker/Lambda in All 30+ Regions)"]
    E --> I["Очистити історію Git за допомогою «git filter-repo» + очистити кешовані перегляди GitHub Commit SHA"]
    F --> I
    G --> I
    H --> J{"Did automated bots rack up a $1,000 to $100,000+ cloud bill?"}
    J -->|"ТАК"| K["Відкрити запит на підтримку платежів AWS/GCP -> Надіслати аудит безпеки після виправлення + Запит на одноразове шахрайство/витік рахунку за одноразове шахрайство"]
    J -->|"НІ"| I

Part 1: Provider-by-Provider Kill-Switch & Forensics Matrix (First 5 Minutes)¶

Скористайтеся цією довідковою таблицею, щоб знайти точну кнопку відкликання, автоматичне сканування GitHub таємного сканування та прихований вектор постійності для ваших витоку облікових даних.

Частина 2: Глибоке занурення: як вигнати зловмисника з вашого облікового запису AWS (The 4-Step Cloud Eviction Protocol)¶

Тому що просочився AWS облікові дані мають найвищий радіус фінансового вибуху (up to $50,000+ per day in EC2/SageMaker/Bedrock bills), ви повинні виконати всі чотири кроки, наведені нижче, щоразу, коли AKIA... або ASIA... ключ потрапляє в публічний репозиторій:

+-----------------------------------------------------------------------------+
|     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   |  |
|  +-----------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------+

Крок 1: Вимкніть обидва Static AKIA Ключ І все відкарбовано ASIA Токени сесії¶

Видалення AKIA ключ у консолі AWS не робить тимчасово недійсним STS повноваження вже видані sts:GetSessionToken. Щоб негайно вбити все через 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": "*"
    }]
  }'

Крок 2: Вистежте користувачів, ролі та ключі доступу IAM Backdoor у CloudTrail¶

Виконайте ці команди AWS CLI, щоб перевірити, чи створив бот прихованого бекдор-користувача IAM або прикріпив вторинний ключ доступу до одного з облікових записів ваших співробітників під час вікна:

# 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

Крок 3: Очистити все 30+ Регіони AWS для екземплярів Rogue EC2, груп автоматичного масштабування та завдань Bedrock/SageMaker¶

Чому жертви все ще отримують a $12,000 рахунок наприкінці місяця після того, як вони «перевірили інформаційну панель EC2 і не побачили жодного випадку»? Оскільки консоль AWS показує лише один регіон за раз (e.g., us-east-1), а бот розкрутився 20 екземпляри в ap-south-1 (Mumbai), eu-north-1 (Stockholm), і sa-east-1 (Sao Paulo) і сховав їх у Групи автоматичного масштабування EC2 (ASGs) так що якщо ви завершуєте примірник EC2 вручну, група автоматичного масштабування запускає заміну 30 seconds пізніше.

Запустіть цей багаторегіональний bash в один рядок, щоб перелічити усі запущені або незавершені екземпляри EC2 у кожному активному регіоні AWS у 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

Частина 3: Видалення таємниці з історії Git (git-filter-repo) і очищення кешу прихованих комітів GitHub¶

Після того, як облікові дані мертві на рівні постачальника, ви повинні видалити секретний рядок зі свого сховища .git фіксувати історію, щоб її не бачили ні колеги, ні майбутні скребки (and so GitHub's Push Protection stops blocking your branches).

1. Чому git rm .env + git commit НЕ видаляє секрет із Git¶

Біг git rm .env && git commit -m "remove env" видаляє файл лише з останнього коміту (HEAD); відкритий секретний текст залишається доступним для читання всередині батьківського коміту (the parent commit) для всіх, хто натисне «Здійснити» на GitHub.

2. Чисто перепишіть історію сховища за допомогою git-filter-repo¶

1. Якщо тільки останній комміт (HEAD) містить секрет (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. Якщо секрет прихований кількома комітами назад у вашій історії (or inside a code file you want to keep): Використовуйте 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. Прихована пастка кешу GitHub (Dangling Commit SHAs)¶

Навіть після бігу git filter-repo і git push --force, Веб-сервери GitHub все ще зберігають старий SHA без посилань («зависаючий») і доступний для всіх за адресою https://github.com/<owner>/<repo>/commit/<old-40-char-sha> (and in any forks or Pull Requests), поки не запуститься збірка сміття. - Як негайно очистити кешований SHA комітів на GitHub: 1. Скопіюйте повністю 40-character SHA коміту витоку коміту перед тим, як ви переписали історію. 2. Відкрити https://support.github.com/contact -> попросити «Видалити конфіденційні дані / Очистити кешовані перегляди для недосяжного коміту SHA» у сховищі owner/repo і надайте точний SHA коміту (or use the GitHub Support portal's automated cache-purge workflow).

Частина 4: Як отримати a $5,000 to $100,000+ Рахунок для ботів AWS або GCP скасовано (The Courtesy Forgiveness Appeal)¶

Що, якщо ви штовхнули .env файл у п’ятницю вдень, не перевіряв свою електронну пошту до ранку понеділка та прокинувся $28,400.00 AWS або Google Cloud виставляє рахунки за крипто-майнінг або LLM-проксі-ботів?

НЕ панікуйте та НЕ анулюйте свою кредитну картку та не подавайте банківський запит на відкликання платежу. Обидва Веб-сервіси Amazon (AWS) і Google Cloud Platform (GCP) мають встановлену внутрішню Політику щодо одноразового випадкового витоку облікових даних/політику кредитування для окремих розробників, студентів і стартапів, за умови, що ви виконали 100% їхнього обов’язкового контрольного списку заходів безпеки до того, як їхня команда розгляду платежів оцінить вашу апеляцію.

5-етапний протокол AWS / GCP Bill Waiver Protocol (90%+ Success Rate for First-Time Leaks)¶

1. Спочатку виконайте кожен крок відновлення безпеки (AWS Will Reject Your Waiver Until the Account Is Clean):
   • Видаліть скомпрометований ключ доступу IAM (and the IAM User if possible).
   • Припиніть роботу кожного несанкціонованого екземпляра EC2, групи автоматичного масштабування, тома EBS, Elastic IP, екземпляра RDS і сегмента S3 у всіх регіонах (verify via AWS Cost Explorer and AWS Billing -> Bills -> Charges by Region that daily accrual has dropped back to $0.00).
   • Увімкнути Hardware або Authenticator App MFA (Multi-Factor Authentication) у вашому кореневому обліковому записі AWS і кожному користувачеві IAM.
2. Відкрийте заявку на підтримку в розділі "Account and Billing" (Free for All AWS/GCP Tiers, No Paid Support Plan Required):
   • Перейти до console.aws.amazon.com/support/home -> Створити запит -> Обліковий запис і виставлення рахунків -> Послуга: Виставлення рахунків -> Категорія: Оспорити стягнення/зламаний рахунок.
3. Подайте цей точний фактичний підсумок усунення та труднощів:
   • Підтвердьте часову шкалу та причину: Чітко вкажіть, коли ключ був випадково відкритий на GitHub (e.g., "October 30 at 22:14 UTC") і коли його було скасовано ("October 31 at 09:05 UTC").
   • Укажіть несанкціоновані стягнення плати за регіонами та службами: Перелічіть точні суми шахрайської діяльності бота в доларах порівняно з вашим звичайним історичним щомісячним рахунком (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").
   • Підтвердити 100% виправлення: Додайте точні кроки, які ви вже виконали (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).
   • Ввічливо подайте запит на одноразове безкоштовне коригування рахунків: Поясніть, що ви індивідуальний розробник / студент / стартап на ранній стадії, що сплачує $18,420 несанкціонований рахунок для бота спричинив би серйозні фінансові труднощі, і вимагайте одноразового безкоштовного виставлення рахунку/звільнення за шахрайське використання.
4. Тимчасово замініть або обмежте пов’язану платіжну картку, якщо автоматичне виставлення рахунків неминуче:
   • Поки ваша заява в службу підтримки платежів AWS розглядається (which usually takes 5 to 15 business days while the AWS Security and Billing Service Teams verify that all rogue resources are terminated), contact AWS Support inside the ticket and ask them to place a temporary billing hold (defer auto-charge) on the disputed invoice so it does not overdraft your bank account while the credit adjustment is being processed.

(For related developer and remote-work security incidents, see Accidental production database drop, git force-push, secret leak, and incident triage, Production database dropped or S3 bucket deleted without recent backup, Accidentally emailed confidential payroll, client PII, or HIPAA spreadsheet, і Emergency remote work security and data privacy.)

Regional data breach and cloud security reporting authorities¶

Часті запитання¶

If I realized I pushed an .env file to a public GitHub repo and made the repo private 2 minutes later, do I still need to rotate my keys?¶

Yes, 100 percent of the keys in that file must be Considered compromised and revoked immediately. Automated credential-harvesting bots do not wait for Google to index your repository; they subscribe directly to GitHub's real-time public `Events API` firehose (`and GH Archive`), which broadcasts every public `PushEvent` globally within 1 to 3 seconds of your `git push`. By the time you clicked "Settings -> Change repository visibility -> Make private" two minutes later, dozens of automated scraper bots had already downloaded your commit diff and queued your AWS, Stripe, OpenAI, and database credentials for exploitation.

Why did bots keep launching EC2 instances in my AWS account even after I deleted the leaked AKIA access key?¶

Deleting a static `AKIA...` access key in AWS IAM only deactivates that specific permanent key; it does not invalidate temporary `ASIA...` Security Token Service (`STS`) session tokens that the attacker already generated using `sts:GetSessionToken` або `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` і `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+ bill if hackers stole my API key from GitHub and mined crypto?¶

In the vast majority of first-time accidental leaks, yes, provided you act quickly, cooperate fully with their security team, and do not ignore the invoice. Both AWS and Google Cloud have an internal one-time courtesy billing adjustment policy for developers and small businesses hit by unauthorized credential-leak spikes. Before requesting the bill waiver under "Account and Billing" support, you must first prove that the leak is 100 percent closed: revoke the exposed IAM keys, terminate all rogue compute instances and Auto Scaling Groups across all 30+ global regions, enable Multi-Factor Authentication (`MFA`) on your root account, and set up AWS Budgets cost alerts.

Why does git rm .env not remove my secret key from GitHub?¶

Git , це незмінна книга керування версіями: коли ви запускаєте `git rm .env` і натиснути новий комміт, Git лише записує, що файл відсутній у найновішому знімку (`HEAD`), зберігаючи повний вміст відкритого тексту `.env` permanently stored inside the previous commit (`the parent commit`) in your repository's commit history. Even if you rewrite your history with `git filter-repo` and force-push, anyone can still read the secret if you haven't revoked it at the provider console. Always revoke and rotate the secret key in your cloud provider's dashboard first, and then use `git filter-repo` to scrub the dead string from your commit history.

Пов'язані посібники¶

• Accidental production database drop, git force-push, secret leak, and incident triage
• Production database dropped or S3 bucket deleted without recent backup
• Випадково надіслано електронною поштою конфіденційну платіжну відомість, ідентифікаційну інформацію клієнта або таблицю HIPAA не тому одержувачу
• Випадкове показ конфіденційної відомості про зарплату, менеджера паролів або списку звільнених у Zoom/Teams
• Emergency remote work security and data privacy
• Номери екстрених служб

Джерела та офіційне керівництво¶

• Веб-служби Amazon (AWS Security Incident Response Guide & AWS Knowledge Center: "What should I do if I notice unauthorized activity or exposed IAM access keys?"): AWSCompromisedKeyQuarantineV2 Правила поведінки, визнання тимчасової недійсною STS Токени сесії (RevokeOldSessions), а також мультирегіональний аудит ресурсів.
• Документація GitHub (GitHub Secret Scanning, Push Protection, & "Removing sensitive data from a repository" using git-filter-repo): Програма автоматичного відкликання партнера (Stripe, AWS, OpenAI, NPM), git-filter-repo Переписування історії та видалення недосяжних кешованих комітів SHA.
• Stripe Inc. (Stripe Developer Security Guide: API Key Rotation & Compromised Key Incident Triage): Негайно sk_live_ Термін дії ключа, аудит /v1/events і /v1/webhook_endpointsі Обмеження ключів через rk_live_ Області застосування.
• NIST (Special Publication 800-61 Rev. 2 / Rev. 3: Computer Security Incident Handling Guide) і OWASP (Secrets Management Cheat Sheet): Зберігання облікових даних, Ефемерна федерація ідентифікації робочого навантаження OIDC (replacing static CI/CD keys) і секретне сканування перед фіксацією.