TL;DR: Нашият анализ показва, че атакуващите вече извличат списъци или изтеглят данни в рамките на 15 минути след проникване в дадена среда, а инструментите, които е трябвало да ги засекат, не са били ефективни. Ще обсъдим три често срещани модела на атака, при които наблюдавахме това поведение.

  • Откраднати токени на разработчици. Отровни npm пакети и инфостийлъри извличат GitHub токени от лаптопи на разработчици; по-късно атакуващите използват тези токени за ексфилтриране на данни от GitHub. GitHub няма вградени механизми за засичане на начина, по който се използва даден токен, оставяйки организациите уязвими към ексфилтрация на код.
  • ClickFix примамки за AI инструменти. Фалшиви команди за инсталиране на Claude Code в споделени чатове на Claude зареждат macOS стийлър, който взема бисквитки от браузъра и идентификационни данни за облака. Самата жертва изпълнява командите, точно както би направила при инсталиране на всеки друг инструмент, което може да задейства или да не задейства засичане на крайната точка.
  • Вишинг (vishing) през отдела за техническа поддръжка. Атакуващите използват социално инженерство и се представят за IT отдела, за да накарат служител да одобри истинска MFA подкана на наподобяваща страница за вход. Доставчиците на идентичност могат да третират влизането на атакуващия като легитимно, което ги прави неефективни при засичането на тези проблеми.

Засичането на тези инциденти изисква детекция, изградена върху данни и поведение. Спирането им изисква автономен отговор. Ние разглеждаме и двете теми.

През март разработчик инсталира GitHub Desktop, вписа се и спря да го използва същия ден. OAuth токенът, който той създаде, стоя в ключодържателя (keychain) на Mac-а 95 дни. На 19 юни някой друг започна да го използва.

Токенът изтегли 76 хранилища за около 15 секунди през домашни проксита в повече от две дузини европейски градове. GitHub не вдигна тревога, защото нищо в GitHub не следи как се използват токените. Платформата Exaforce го маркира в рамките на пет минути и го триажира в рамките на 10 минути.

Нашите MDR анализатори потвърдиха ексфилтрацията и уведомиха клиента минути след като засичането се задейства. Но докато бъдат предприети каквито и да е действия, атакуващият вече беше ексфилтрирал данни от 472 от 638-те хранилища.

Този случай показва и двете страни на проблема. Без засичане на аномалии никой нямаше да разбере, че токенът се използва. При наличие на правилно засичане овладяването все още би изисквало човешко одобрение, давайки на атакуващия достатъчно време за ексфилтриране на данни.

Спящи токени на лаптопи на разработчици

Функциите за сигурност на GitHub са фокусирани върху инспектирането на код и тайни, а не върху злоупотребата с токени. Ние засякохме този компрометиран токен на GitHub чрез натрупване на слаби сигнали за една-единствена сесия в GitHub. Влизанията в профила идваха от мрежи и градове, които никога преди не бяха виждани.

Той изтегляше ZIP архиви с машинна скорост, с потребителски агент на Windows, в акаунт, който винаги е използвал само macOS. Всеки от тези сигнали потенциално може да бъде обяснен, но всички те заедно са показателни за нещо злонамерено.

Токените за OAuth приложения като този, с префикс gho_ , нямат срок на валидност, а GitHub ги оттегля сам едва след една година. При нашите тестове SSO страницата на организацията дори не изброява тези токени и те са видими само през CLI. Деактивирането на разработчика в доставчика на идентичност също не спира токена.

Без SCIM GitHub продължава да зачита токените, докато някой не ги отмени или не премахне потребителя от организацията.

Разработчиците, използващи AI инструменти за писане на код, инсталират npm пакети и свързват MCP сървъри по цял ден, предимно извън пайплайните, които екипите по сигурност наблюдават, а червеи като Shai-Hulud претърсват машината за GitHub и облачни токени в момента, в който бъде инсталиран отровен пакет.

Това се случва преди каквото и да е да бъде къмитнато, поради което сканирането на вашите хранилища, за да се определи дали компрометиран npm пакет може да ви е засегнал, не е достатъчно.

ClickFix се насочва към инсталации на AI инструменти

Кражбата на токен от ключодържателя на macOS обикновено изисква инфостийлър, който фишингва паролата за вход.

Най-новите ClickFix примамки се възползват от доверието в AI инструментите. При един такъв инцидент служител, който търсел инструкции за инсталиране на Claude Code, попаднал на споделен разговор в Claude с команда за инсталиране от един ред.

Командата зарежда macOS стийлър (направихме задълбочен анализ с индикатори), който фалшифицира подкана от системните настройки за паролата, след което копира ключодържателя, бисквитките на браузъра, запазените пароли и идентификационните данни за облака.

Тъй като жертвата сама изпълнява командата, филтрирането на имейли и контролите за изтегляне биват заобиколени. Най-ефективният подход за засичане на тези видове атаки е решение за засичане на крайни точки. Оценката на мащаба на въздействието трябва да включва цялостен анализ на всички токени/идентификационни данни, генерирани от потребителя.

Вижте как агентите на Exaforce овладяват атаки срещу идентичността

Отвлечената сесия дава на атакуващия достъп до всяко приложение, в което вашите потребители влизат.

Заявете демонстрация, за да видите как агентите на Exaforce засичат и овладяват атаки срещу идентичността във вашата среда.

Фалшиви обаждания от IT поддръжката, завършващи с откраднати сесии

В случаите на вишинг, по които работихме тази година, атакуващият регистрираше свое собствено MFA устройство и стартираше скрипт за групово изтегляне 2,5–7 минути след като жертвата одобреше push известието. В един такъв случай атакуващият ексфилтрира 140 000 файла и поиска откуп за изтеклите данни.

Повечето от тези обаждания следват сценария за техническа поддръжка, използван често от групата Scattered Spider. Обаждащият се, представящ се за IT поддръжка, изпраща служителя на страница за вход с името на компанията в URL адреса, като например тематичната за passkey страница contoso.add-passkey[.]com в доклада на Microsoft от септември.

Страницата или препредава влизането чрез прокси противник-по-средата (adversary-in-the-middle, AiTM), или атакуващият напътства жертвата през процес на влизане с код на устройството (device-code sign-in).

Един инструментариум, който разглобихме, хостван на oskeysetup[.]com, беше написан от нулата, така че засичанията, изградени за Evilginx и другите публични пакети, няма да бъдат ефективни.

В повечето случаи наблюдавахме, че детекциите от доставчиците на идентичност са неефективни, тъй като жертвите одобряват истинска MFA подкана. При отвличане на сесия през юли, по което работихме, Microsoft първоначално маркира първото влизане на атакуващия като рисково, а след това маркира риска като отстранен, тъй като потребителят е преминал MFA. В рамките на минути откраднатият токен беше използван повторно от две други държави в рамките на една секунда, а по-късните сигнали на Microsoft повишиха нивото на риск за потребителя.

Exaforce го засече, като свърза влизанията в Okta и Microsoft заедно и ги провери спрямо историята на потребителя: това беше първото влизане на акаунта от Съединените щати, на устройство с Linux и през домашен интернет доставчик, който акаунтът никога не беше използвал. В тези случаи най-ранният силен сигнал обикновено е нов MFA метод от устройство и мрежа, до които потребителят никога не се е докосвал.

Забелязахме също, че атакуващите се прицелват в една и съща компания през множество служители, често използвайки едни и същи сървъри и домейни.

Действия за автономен отговор

Ефективен подход за противодействие на обсъдените до момента инциденти е преминаването към автономен отговор. Автоматизирането на реакцията със сигурност не е новост, но опасенията винаги са били свързани с последствията от погрешно действие, което може да блокира достъпа на ръководен кадър или да наруши работна интеграция в производствена среда.

Установяваме, че е по-добре действията да се сортират според степента на затруднение: колко би струвало едно погрешно действие по реагиране на лицето, което притежава идентификационните данни? Ако то му струва повторно влизане в профила или повторно регистриране на телефон, действието е с ниско ниво на затруднение и може да се задейства при констатация с висока степен на достоверност. Това обхваща прекратяване на сесии, премахване на MFA метод, регистриран по време на маркираната сесия, и деактивиране на ключ, който може да бъде включен отново.

Нулирането на пароли, деактивирането на акаунти, окончателните изтривания и всичко, от което зависи производствена услуга, следва да изискват одобрение от човек. Този човек може да бъде целевият потребител и неговият пряк ръководител, потвърждаващи с кратко съобщение, че влизането не е било извършено от тях.

Въпреки че повечето от обсъжданите действия са свързани със самоличност или свързаните с нея идентификационни данни, те не могат да се ограничават само до доставчика на идентичност (IdP). Нулирането на паролата на потребителя в Okta или прекратяването на неговата сесия в Okta не отменя токените, които Microsoft 365, Google Workspace или GitHub вече са издали, а сесиите в AWS и Snowflake, стартирани чрез SSO, продължават да работят.

В нашите случаи на вишинг (vishing) установихме, че източването на данни е продължило между 44 минути и 3 часа след прекратяването на сесията на потребителя в IdP, а в един от случаите правилата за входящата поща, създадени от атакуващия, останаха активни и след нулиране на паролата. Universal Logout на Okta достига до някои приложения като Google Workspace и Slack, но не и до GitHub, Snowflake или доставчиците на AI модели.

Най-добре е действията по отнемане на достъп за всяко приложение да бъдат изградени предварително, заедно с акаунта, който ги изпълнява. Бяхме свидетели как действие по реагиране се провали по средата на инцидент с грешка 403, тъй като никой не беше предоставил необходимите разрешения.

Изграждането на такива механизми за реакция за всеки източник на данни може да изглежда обезсърчително. Препоръчваме да започнете с услугите, в които се съхраняват най-критичните ви данни.

  • Продуктивност: Google Workspace, Office 365, Box, Dropbox, Slack
  • Облачни услуги: AWS, GCP, Azure
  • AI услуги: Anthropic, OpenAI
  • Данни: Snowflake, Databricks
  • Код: GitHub, GitLab

Препоръчителни реакции с ниско ниво на затруднение, с които да започнете, и начини за внедряването им:

OKTA

Действие: Прекратяване на сесии и OAuth токени, издадени от Okta API: DELETE /api/v1/users/{id}/sessions?oauthTokens=true Необходими разрешения: обхвати okta.users.read и okta.users.manage, плюс персонализирана администраторска роля, съдържаща само okta.users.read и okta.users.lifecycle.clearSessions

Действие: Нулиране на всички фактори за автентикация на потребителя, включително тези на атакуващия API: POST /api/v1/users/{id}/lifecycle/reset_factors Необходими разрешения: Същите обхвати, с добавен okta.users.credentials.resetFactors към ролята

Microsoft Entra ID

Действие: Оттегляне на токени за опресняване (refresh tokens) и сесийни бисквитки API: POST /users/{id}/revokeSignInSessions Необходими разрешения: User.RevokeSessions.All, плюс User.Read.All за справка за потребителя

Действие: Изтриване на MFA методите на потребителя, включително тези на атакуващия API: DELETE /users/{id}/authentication/{type}Methods/{methodId} за всеки телефон, приложение Authenticator, софтуерен OATH, FIDO2, Windows Hello и метод с Temporary Access Pass Необходими разрешения: UserAuthenticationMethod.ReadWrite.All, плюс User.Read.All

Google Workspace

Действие: Прекратяване на уеб и сесии на устройства, както и оттегляне на OAuth токените на приложението API: POST /admin/directory/v1/users/{userKey}/signOut, DELETE /admin/directory/v1/users/{userKey}/tokens/{clientId} Необходими разрешения: обхват admin.directory.user.security, плюс делегирана администраторска роля

GitHub Enterprise Cloud, SAML SSO на ниво организация

Действие: Изтриване на откраднатия токен от организацията API: GET /orgs/{org}/credential-authorizations?login= {user} за откриването му, след което DELETE /orgs/{org}/credentialauthorizations/{credential_id} Необходими разрешения: Собственик на организацията (Org owner) с admin:org или GitHub App с Administration на организацията (write). Няма по-ограничена възможност

Snowflake

Действие: Деактивиране на токен за програмен достъп API: Ваш собствен SQL, като например ALTER USER {name} MODIFY PAT {token} SET DISABLED TRUE, изпратен през SQL API POST /api/v2/statements) Необходими разрешения: Специален сервизен потребител, чиято роля разполага с MODIFY PROGRAMMATIC AUTHENTICATION METHODS върху съответния потребител

AWS

Действие: Прекратяване на STS сесиите, вече издадени на IAM потребител API: PutUserPolicy с вградено правило за отказ (inline deny) за сесии, издадени преди настоящия момент (aws:TokenIssueTime) Необходими разрешения: iam:PutUserPolicy, плюс iam:GetUser и iam:GetUserPolicy

Anthropic

Действие: Деактивиране на API ключ API: POST /v1/organizations/api_keys/{id} с {"status":"inactive"} Необходими разрешения: Администраторски API ключ

Как Exaforce се справи с тези атаки

Exaforce е агентна SOC платформа с опционална MDR услуга. Нашите агенти (Exabots) поемат инженерната дейност по засичане, триажа на сигнали за тревога, разследванията, търсенето на заплахи (threat hunting) и реакцията. Агентите работят върху унифицирана платформа за данни, която може да функционира като вашата SIEM система или да работи съвместно с нея.

Платформата разполага с 800 детекции на аномалии, базирани на AI/ML, които помагат за откриването на описаните видове инциденти в критични облачни услуги, SaaS, идентичности, крайни точки и AI услуги. Налице са над 100 динамични действия за реакция, които агентите могат да изпълняват, така че да не се налага сами да ги изграждате и поддържате за всички свои критични услуги.