Компрометация Gitea после RCE: какие IoC искать в репозитории

Компрометация Gitea после RCE редко заканчивается одним запуском команды. Злоумышленник получает путь к данным и учётным записям. Затем он ищет способы сохранить доступ.

Что такое Gitea. Gitea — это легковесный self-hosted Git-сервис, аналог GitHub или GitLab, который компании разворачивают на собственных серверах. Через Gitea команды хранят исходный код. Компрометация такого сервера даёт злоумышленнику прямой доступ к репозиториям и CI/CD-секретам.

Репозитории становятся важным источником признаков атаки. В них видны новые коммиты, ветки, метки, файлы сборки и зависимости. Но один странный коммит ещё не доказывает взлом.

🔍 Что именно происходит после RCE

RCE означает удалённое выполнение кода. В рассматриваемом сценарии команда запускается на сервере Gitea. Она выполняется от имени служебной учётной записи Gitea.

Источник описывает CVE-2026-60004 как критическую уязвимость. Оценка CVSS составляет 9,8. Проблема затрагивает версии Gitea от 1.17 до 1.27.1 включительно.

Сценарий связан с Git-хуком. Автор репозитория с правом записи может превратить содержимое патча в действующий хук. Такой хук запускает команды оболочки.

Вызов API требует входа и права записи. При включённой регистрации посторонний посетитель может создать обычную учётную запись. Он также может создать репозиторий на немодифицированном экземпляре.

В рекомендации Gitea нет утверждения об эксплуатации в реальных атаках. При этом там указан общедоступный код проверки концепции. Поэтому расследование должно учитывать подтверждённый риск, но не объявлять атаку доказанной без следов.

Сделайте сейчас: зафиксируйте версию Gitea, режим регистрации и права записи. Эти данные задают границы проверки.

📌 Границы расследования и рабочие гипотезы

Сначала определите конкретный экземпляр Gitea. Запишите его имя, адрес, версию и способ установки. Укажите операционную систему и имя служебной учётной записи.

Отдельно отметьте период подозрительной активности. Используйте единую временную шкалу в UTC. Так проще сопоставить события Gitea, веб-сервера и операционной системы.

Составьте список организаций и репозиториев. Включите публичные и закрытые проекты. Не забудьте зеркала, архивы и репозитории с Git LFS.

Разделяйте факты и предположения. Факт — найден неизвестный токен. Гипотеза — токен создали после RCE. Для каждой гипотезы укажите нужное подтверждение.

• Версия Gitea и дата последнего обновления.
• Способ установки: пакет, контейнер или ручная сборка.
• Период входов и изменений.
• Список администраторов и владельцев проектов.
• Связанные системы сборки и развёртывания.

Не связывайте инцидент с неподходящими CVE. В предоставленных данных нет других подтверждённых CVE для Gitea. Номер CVE-2026-60004 относится к описанному сценарию с Git-хуком.

Сделайте сейчас: создайте карточку инцидента. Внесите туда версии, адреса, время и список затронутых проектов.

🧾 Журналы Gitea: следы учётных записей

Журналы Gitea помогают увидеть действия внутри платформы. Проверяйте успешные и неудачные входы. Сопоставляйте их с адресами и временем.

Ищите создание и удаление пользователей. Отдельно смотрите смену ролей и прав. Особое внимание нужно уделить новым администраторам.

Проверьте выпуск и отзыв токенов. Неожиданный токен может дать доступ без нового входа. Зафиксируйте владельца, время создания и время последнего использования.

Проверяйте операции с ключами SSH. Ищите новые ключи у пользователей, ботов и организаций. Сравнивайте отпечатки с утверждённым реестром ключей.

• Успешные и неудачные аутентификации.
• Создание, удаление и блокировка пользователей.
• Изменение ролей и прав доступа.
• Выпуск, использование и отзыв токенов.
• Добавление и удаление SSH-ключей.
• Создание OAuth-приложений.
• Изменение веб-перехватчиков.
• Действия администраторов и API-запросы.

Особенно полезны редкие действия. Например, пользователь впервые создаёт OAuth-приложение. Или бот меняет права проекта вне окна работ.

Не считайте любой API-запрос вредоносным. Сначала найдите нормальный профиль этого пользователя. Сравните адрес, время, частоту и объект запроса.

Сделайте сейчас: выгрузите журналы входов, API, токенов, ключей и прав. Сохраните исходные файлы без редактирования.

⚙️ Серверные журналы и запуск команд

Следующий слой проверки находится за пределами Gitea. Изучите журналы веб-сервера и обратного прокси. Ищите необычные запросы к API и панели управления.

Сопоставьте запросы с процессами на узле. Полезны события создания процессов и изменения файлов. Важны точное время, родительский процесс и служебная учётная запись.

Проверьте SSH и sudo. Ищите входы вне обычных адресов. Отдельно отметьте команды с повышенными правами.

Изучите systemd и планировщик заданий. Неизвестная служба может сохранять доступ после перезапуска. Неожиданная задача может запускать скрипт по расписанию.

• Журналы веб-сервера и обратного прокси.
• События systemd и запуск новых служб.
• Входы по SSH и действия sudo.
• Задания планировщика.
• Новые сетевые соединения.
• Создание процессов и дочерние процессы.
• Изменения файлов в каталоге Gitea.

Проверьте, не менялись ли права на файлы. Ищите новые исполняемые файлы и скрипты. Сравнивайте их с доверенной копией сервера.

Сетевые соединения оценивайте вместе с журналами. Один внешний адрес не доказывает управление сервером. Но постоянное соединение после подозрительного запуска требует проверки.

Сделайте сейчас: объедините журналы Gitea, прокси, SSH и systemd. Приведите время всех записей к UTC.

🧩 Коммиты, ветки и переписанная история

Проверка репозитория начинается с истории изменений. Ищите коммиты, которых нет в рабочих задачах. Смотрите автора, дату, сообщение и владельца учётной записи.

Сравнивайте адрес автора коммита с адресом входа. Сверяйте подпись коммита, если проект её использует. Несовпадение не всегда означает атаку, но требует объяснения.

Ищите новые ветки и метки. Скрытая ветка может содержать изменённый код. Новая метка может указывать сборочную систему на нежелательный снимок.

Проверяйте переписывание истории. Исчезнувшие коммиты и новые цепочки требуют отдельной фиксации. Сравнивайте локальные копии, зеркала и резервные копии.

• Неожиданные коммиты и авторы.
• Новые ветки с непонятными именами.
• Неизвестные метки и релизные указатели.
• Изменение порядка коммитов.
• Исчезновение прежней истории.
• Различия между сервером и доверенной копией.

Не путайте автоматический коммит с вредоносным изменением. Боты и процессы CI/CD могут менять код сами. Сначала найдите владельца автоматизации и расписание.

Полезно составить таблицу «изменение — автор — время — источник». Она показывает связи между Git, журналами и задачами сборки.

Сделайте сейчас: выгрузите список всех веток, меток и коммитов. Зафиксируйте их хеши до любых исправлений.

🛠️ Файлы, которые часто меняют после доступа

Проверьте файлы, влияющие на сборку и развёртывание. Начните с конфигураций CI/CD. Ищите новые задания, команды и адреса загрузки.

Посмотрите изменения в .gitignore. Такой файл может скрыть вредный или секретный файл. Само изменение не доказывает атаку. Важны автор и причина.

Проверьте зависимости. Сравните имена, версии и источники пакетов. Отдельно изучите новые зависимости без связи с задачей проекта.

Изучите контейнерные описания и сценарии сборки. Ищите новые образы, команды запуска и внешние загрузки. Такие изменения влияют на среду выполнения.

• Файлы рабочих процессов CI/CD.
• Конфигурации сборки и развёртывания.
• .gitignore и файлы окружения.
• Сценарии Git-хуков.
• Файлы зависимостей и блокировки версий.
• Dockerfile и другие контейнерные описания.
• Документация с новыми командами или адресами.

Отдельно проверьте скрипты хуков. В описанном сценарии Git-хук имеет особое значение. Ищите новые файлы и изменения прав на запуск.

Документация тоже важна. Злоумышленник может добавить туда команду для разработчиков. Такой текст способен привести к повторному запуску опасного действия.

Сделайте сейчас: сравните файлы сборки с последней доверенной копией. Отдельно вынесите все новые команды и внешние адреса.

📦 Поиск признаков кражи данных

После получения доступа злоумышленник может читать код и секреты. Поэтому проверяйте не только изменения файлов. Смотрите действия чтения и выгрузки.

Ищите массовое клонирование репозиториев. Сравнивайте число операций с обычным профилем пользователя. Резкий рост за короткое время требует объяснения.

Проверьте скачивание архивов. Такой путь удобен для получения проекта без обычного клонирования. Отдельно изучите архивы закрытых репозиториев.

Git LFS требует отдельной проверки. Большие файлы могут не попадать в обычный анализ Git. Ищите необычные обращения к объектам LFS.

• Массовое клонирование закрытых проектов.
• Частое скачивание архивов.
• Необычные обращения к Git LFS.
• Серия API-запросов на чтение.
• Использование токена из нового адреса.
• Использование SSH-ключа вне обычного времени.

Проверьте секреты в истории. Это ключи, пароли, токены и файлы окружения. Даже удалённый секрет мог сохраниться в старом коммите.

Свяжите действия с владельцем. Пользователь мог запускать резервное копирование. Тогда массовое чтение имеет законную причину. Причину нужно подтвердить журналом задания.

Сделайте сейчас: составьте список чтения по пользователям и проектам. Отметьте все операции, которые выходят за обычный объём.

🧪 Легитимная автоматизация или вредоносное изменение

Gitea работает рядом с ботами, зеркалами и CI/CD. Эти системы создают коммиты и запускают задания. Поэтому автоматический след не равен IoC.

Сначала составьте карту автоматизации. Укажите бота, владельца, расписание и используемый токен. Добавьте связанные веб-перехватчики и проекты.

Затем сравните событие с картой. Нормальный бот действует в известных репозиториях. Он использует ожидаемый адрес и повторяемое расписание.

Подозрительный след нарушает хотя бы одно правило. Например, токен работает в новом проекте. Или бот меняет файл вне обычного процесса выпуска.

• Сверяйте автора с владельцем автоматизации.
• Сверяйте время с расписанием.
• Проверяйте адрес источника запроса.
• Сопоставляйте токен с назначением.
• Сравнивайте изменения с заявленной задачей.

Заранее создайте список разрешённых действий. Это упростит проверку после инцидента. Список должен включать ботов, зеркала и сервисы сборки.

Не удаляйте спорный коммит до фиксации. Сначала сохраните его хеш и содержимое. Потом принимайте решение вместе с владельцем проекта.

Сделайте сейчас: запросите у владельцев CI/CD список ботов и токенов. Сверьте его с текущими настройками Gitea.

🔐 Сохранение доказательств до очистки

Очистка сервера до копирования журналов уничтожает следы. Сначала ограничьте доступ к узлу. Затем сохраняйте данные в неизменном виде.

Зафиксируйте снимок диска или виртуальной машины. Сохраните копию каталогов Gitea и журналов. Работайте только с копиями.

Для каждого файла посчитайте хеш. Запишите алгоритм, значение и время расчёта. Хеш помогает доказать неизменность копии.

Сохраните метаданные файлов. Важны владелец, права, размер и время изменения. Эти поля помогают восстановить порядок событий.

• Снимок диска или виртуальной машины.
• Копии журналов Gitea и операционной системы.
• Копия конфигурации веб-сервера и прокси.
• Список процессов и сетевых соединений.
• Список пользователей, ключей и токенов.
• Хеши всех собранных файлов.
• Временная шкала в UTC.

Не запускайте исправления на единственной копии. Даже просмотр может изменить временные метки. Для анализа используйте отдельный рабочий экземпляр.

Каждое действие записывайте в журнал расследования. Укажите исполнителя, время и результат. Так команда не повторит опасное действие.

Сделайте сейчас: назначьте владельца доказательств. Он контролирует копирование, хеширование и доступ к материалам.

🚧 Сдерживание и восстановление доступа

После первичной фиксации изолируйте экземпляр Gitea. Не отключайте его без плана сохранения данных. Сначала определите, какие системы зависят от репозиториев.

Отзовите токены и подозрительные SSH-ключи. Заблокируйте неизвестные сессии. Проверьте учётные записи администраторов и владельцев проектов.

Проверьте веб-перехватчики и OAuth-приложения. Удаляйте только объекты, которые уже зафиксированы. Иначе расследование потеряет важные сведения.

Смените секреты CI/CD. Включите в ротацию ключи, пароли и токены. Учитывайте секреты, которые могли попасть в историю Git.

• Изолируйте подозрительный экземпляр.
• Отзовите токены и SSH-ключи.
• Заблокируйте подозрительные сессии.
• Проверьте администраторов и права проектов.
• Проверьте веб-перехватчики и OAuth-приложения.
• Смените секреты CI/CD.
• Обновите Gitea до версии 1.27.1.

Источник указывает версию 1.27.1 как исправленную для CVE-2026-60004. Обновление является основной мерой устранения этой уязвимости.

Восстанавливайте сервис из доверенной резервной копии. Перед возвратом проверьте пользователей, ключи, хуки и настройки сборки. Затем повторите поиск IoC.

Сделайте сейчас: составьте план изоляции и ротации. Укажите порядок действий для Gitea, CI/CD и связанных систем.

✅ Когда расследование можно завершить

Расследование заканчивается не после удаления одного файла. Сначала проверьте все организации и репозитории. Включите архивы, зеркала и проекты с Git LFS.

Убедитесь, что нет неизвестных учётных записей. Проверьте все ключи, токены, OAuth-приложения и веб-перехватчики. Для каждого объекта должен быть владелец.

Проверьте целостность истории. Сравните хеши с доверенными копиями. Отдельно подтвердите отсутствие неожиданных веток и меток.

Завершите ротацию секретов. Проверьте журналы после восстановления. Новые события должны соответствовать нормальному профилю работы.

• Неизвестные пользователи отсутствуют.
• Неизвестные ключи и токены отозваны.
• OAuth-приложения проверены.
• Веб-перехватчики подтверждены владельцами.
• Все репозитории прошли проверку.
• История и хеши сверены.
• Секреты CI/CD заменены.
• Контроль целостности включён.

Сохраните итоговую временную шкалу. Отдельно запишите подтверждённые факты и версии событий. Укажите, какие данные проверить не удалось.

После закрытия инцидента оставьте регулярный контроль. Он должен отслеживать новые пользователи, токены, ключи, хуки и массовое чтение. Такой контроль помогает заметить повторный доступ.

Сделайте сейчас: оформите критерии закрытия письменно. Закройте расследование только после проверки каждого пункта.

📚 Читайте также

• Что на самом деле подтверждает C2PA: криптография против мифов
• Фальшивый криптостартап: как КНДР вербует разработчиков и хакеров
• Как построить open source стек мониторинга промышленной инфраструктуры
• Как защитить корпоративную почту от фишинга с подменой домена
• Безопасность кода, написанного ИИ: риски и практики защиты приложений

📖 Термины

CI/CD · RCE (Remote Code Execution) · Threat Hunting · Бэкдор · Индикаторы компрометации (IoC)

🔗 Источники

• CVE-2022-42968: Gitea RCE Vulnerability(2026-08-19 ✓)
• Новая функция RCE в Gitea позволяет авторам репозиториев устанавливать Git-хук для запуска команд оболочки(2026-08-19 ✓)