Mashina tezligidagi hujumlar mashina tezligida aniqlash va javob berishni talab qiladi

Mashina tezligidagi hujumlar mashina tezligida aniqlash va javob berishni talab qiladi

Homiy: Exaforce

2026-yil 22-oktabr

10:02

0

TL;DR: Bizning tahlilimiz shuni ko'rsatadiki, hujumchilar muhitga kirganidan so'ng 15 daqiqa ichida ma'lumotlarni ro'yxatga olish yoki yuklab olishni boshlaydilar va ularni ushlashi kerak bo'lgan vositalar samarali emas edi. Biz ushbu xatti-harakatni kuzatgan uchta keng tarqalgan hujum naqshini muhokama qilamiz.

O'g'irlangan dasturchi tokenlari. Zaharlangan npm paketlari va infostealerlar dasturchi noutbuklaridan GitHub tokenlarini tortib oladi; hujumchilar keyinchalik ushbu tokenlardan GitHub'dan ma'lumotlarni o'g'irlash uchun foydalanadilar. GitHub token qanday ishlatilishini nazorat qiladigan mahalliy aniqlash tizimiga ega emas, bu esa korxonalarni kod o'g'irlanishiga nisbatan zaif qoldiradi.

AI vositalari uchun ClickFix tuzoqlari. Umumiy Claude suhbatlarida soxta Claude Code o'rnatish buyruqlari macOS stealerini yuklaydi, u brauzer cookie-fayllari va bulut ma'lumotlarini o'g'irlaydi. Jabrlanuvchi buyruqlarni o'zi bajaradi, xuddi har qanday vositani o'rnatayotgandek, bu esa endpoint aniqlash tizimini ishga tushirishi yoki tushirmasligi mumkin.

Yordam stoli vishingi. Hujumchilar ijtimoiy muhandislikdan foydalanib, o'zlarini IT xodimi sifatida ko'rsatadilar va xodimni haqiqiy MFA so'rovini o'xshash kirish sahifasida tasdiqlashga majbur qiladilar. Shaxsni tasdiqlovchi provayderlar hujumchining kirishini qonuniy deb qabul qilishlari mumkin, bu esa ularni ushbu muammolarni aniqlashda samarasiz qiladi.

Ushbu hodisalarni ushlash ma'lumot va xatti-harakatga asoslangan aniqlash tizimini talab qiladi. Ularni to'xtatish esa avtonom javobni talab qiladi. Biz ushbu ikkala mavzuni ham qamrab olamiz.

Mart oyida bir dasturchi GitHub Desktop'ni o'rnatdi, tizimga kirdi va o'sha kuni foydalanishni to'xtatdi. Uning yaratgan OAuth tokeni Mac kalit zanjirida 95 kun davomida saqlanib qoldi. 19-iyun kuni boshqa kimdir uni ishlata boshladi.

Token 15 soniya ichida 24 dan ortiq Yevropa shaharlaridagi turar-joy proksi-serverlari orqali 76 ta omborni yuklab oldi. GitHub hech qanday ogohlantirish bermadi, chunki GitHub'da tokenlar qanday ishlatilishini kuzatuvchi hech narsa yo'q. Exaforce platformasi buni besh daqiqa ichida aniqladi va 10 daqiqa ichida triage qildi.

Bizning MDR tahlilchilarimiz aniqlash ishga tushganidan bir necha daqiqa o'tib, ma'lumot o'g'irlanishini tasdiqladilar va mijozni xabardor qildilar. Ammo har qanday chora ko'rilgunga qadar, hujumchi 638 ta omborning 472 tasidan ma'lumotlarni o'g'irlab bo'lgan edi.

Ushbu holat muammoning ikkala tomonini ham ko'rsatadi. Anomaliya aniqlash tizimisiz, hech kim token ishlatilayotganini bilmas edi. To'g'ri aniqlash tizimi mavjud bo'lsa ham, cheklash hali ham inson tasdiqlashini talab qilardi, bu esa hujumchiga ma'lumotlarni o'g'irlash uchun yetarli vaqt berdi.

Dasturchi noutbuklaridagi uxlayotgan tokenlar

GitHub'ning xavfsizlik xususiyatlari kod va sirlarni tekshirishga qaratilgan, token suiiste'moliga emas. Biz ushbu GitHub tokeni buzilishini bitta GitHub sessiyasida zaif signallarni birlashtirish orqali ushladik. Hisobga kirishlar avval hech qachon ko'rilmagan tarmoqlar va shaharlardan amalga oshirildi.

U ZIP arxivlarini mashina tezligida, Windows foydalanuvchi agenti bilan, faqat macOS'dan foydalanilgan hisobda yuklab olayotgan edi. Ushbu signallarning har biri alohida tushuntirilishi mumkin, ammo ularning barchasi birgalikda zararli bir narsani ko'rsatadi.

Ushbu turdagi OAuth ilova tokenlari, gho_ prefiksi bilan, muddati tugamaydi va GitHub ularni faqat bir yildan keyin o'z-o'zidan bekor qiladi. Bizning sinovimizda, tashkilotning SSO sahifasi hatto ushbu tokenlarni ro'yxatga olmaydi va ular faqat CLI orqali ko'rinadi. Shaxsni tasdiqlovchi provayderda dasturchini o'chirish ham tokenni to'xtatmaydi.

SCIMsiz, GitHub tokenlarni kimdir ularni bekor qilmaguncha yoki foydalanuvchini tashkilotdan olib tashlamaguncha hurmat qilishda davom etadi.

AI kodlash vositalaridan foydalanadigan dasturchilar npm paketlarini o'rnatadilar va MCP serverlarini ulaydilar, asosan xavfsizlik jamoalari nazorat qiladigan quvurlar tashqarisida, va Shai-Hulud kabi qurtlar zaharlangan paket o'rnatilganda darhol mashinadan GitHub va bulut tokenlarini qidiradi.

Bu hech narsa commit qilinishidan oldin sodir bo'ladi, shuning uchun omborlaringizni tekshirib, zaharlangan npm paketi sizga ta'sir qilganligini aniqlash yetarli emas.

ClickFix AI vositalarini o'rnatishga qaratilgan

MacOS kalit zanjiridan token o'g'irlash odatda kirish parolini so'raydigan infostealerni talab qiladi.

So'nggi ClickFix tuzoqlari AI vositalaridan ishonchni foydalanadi. Bunday hodisalardan birida, Claude Code o'rnatish ko'rsatmalarini qidirayotgan xodim bir qatorli o'rnatish buyrug'i bilan umumiy Claude suhbatiga duch keldi.

Buyruq macOS stealerini yuklaydi (biz ko'rsatkichlar bilan chuqur tahlil qildik), u tizim sozlamalari soxta so'rovini parol uchun ko'rsatadi, keyin kalit zanjirini, brauzer cookie-fayllarini, saqlangan parollarni va bulut ma'lumotlarini nusxalaydi.

Jabrlanuvchi buyruqni o'zi bajargani uchun, elektron pochta filtrlash va yuklab olish nazorati chetlab o'tiladi. Ushbu turdagi hujumlarni ushlashning eng samarali yondashuvi endpoint aniqlash yechimidir. Ta'sir doirasini baholash foydalanuvchi tomonidan yaratilgan barcha tokenlar/ma'lumotlarning keng qamrovli tahlilini o'z ichiga olishi kerak.

Exaforce agentlari shaxsni tasdiqlash hujumlarini qanday cheklashini ko'ring

O'g'irlangan sessiya hujumchiga foydalanuvchilaringiz kiradigan har bir ilovaga kirish imkonini beradi.

Exaforce agentlari sizning muhitda shaxsni tasdiqlash hujumlarini qanday aniqlashi va cheklashini ko'rish uchun demo buyurtma qiling.

Demo so'rang

Soxta IT qo'ng'iroqlari o'g'irlangan sessiyalar bilan tugaydi

Biz bu yil ishlagan vishing holatlarida, hujumchi o'zining MFA qurilmasini ro'yxatdan o'tkazdi va jabrlanuvchi so'rovni tasdiqlaganidan 2,5-7 daqiqa o'tib, ommaviy yuklab olish skriptini boshladi. Bunday holatlardan birida, hujumchi 140 000 ta faylni o'g'irladi va o'g'irlangan ma'lumotlar uchun to'lov talab qildi.

Ushbu qo'ng'iroqlarning aksariyati Scattered Spider guruhi tomonidan keng qo'llaniladigan yordam stoli skriptiga amal qiladi. IT sifatida o'zini ko'rsatgan qo'ng'iroq qiluvchi xodimni kompaniya nomi URL'da bo'lgan kirish sahifasiga yuboradi, masalan, Microsoft'ning sentyabr yozuvidagi passkey mavzusidagi contoso.add-passkey[.]com.

Sahifa kirishni dushman-o'rtada (AiTM) proksi orqali uzatadi yoki hujumchi jabrlanuvchini qurilma-kod kirishi orqali yo'naltiradi.

Biz tahlil qilgan bir to'plam, oskeysetup[.]com'da joylashtirilgan, noldan yozilgan, shuning uchun Evilginx va boshqa ommaviy to'plamlar uchun qurilgan aniqlash tizimlari samarali bo'lmaydi.

Ko'p hollarda, biz shuni kuzatdikki, shaxsni tasdiqlovchi provayderlardan aniqlash tizimlari samarasiz, chunki jabrlanuvchilar haqiqiy MFA so'rovini tasdiqlaydilar. Iyul oyida biz ishlagan sessiya o'g'irlashida, Microsoft hujumchining birinchi kirishini xavfli deb belgiladi, keyin foydalanuvchi MFA'dan o'tgani uchun xavfni bartaraf etilgan deb belgiladi. Bir necha daqiqa ichida, o'g'irlangan token bir soniya ichida boshqa ikki mamlakatdan qayta ishlatildi va Microsoft'ning keyingi ogohlantirishlari foydalanuvchining xavf darajasini oshirdi.

Exaforce buni Okta va Microsoft kirishlarini bir-biriga bog'lab va foydalanuvchi tarixi bilan solishtirish orqali ushladi: bu hisobning AQShdan birinchi kirishi, Linux qurilmasida va hisob hech qachon ishlatmagan uy ISP orqali edi. Bunday hollarda eng erta kuchli signal odatda foydalanuvchi hech qachon tegmagan qurilma va tarmoqdan yangi MFA usuli hisoblanadi.

Biz shuningdek, hujumchilar bir xil kompaniyani bir nechta xodimlar orqali nishonga olishlarini, ko'pincha bir xil serverlar va domenlardan foydalanishlarini kuzatdik.

Avtonom javob choralari

Shu paytgacha muhokama qilingan hodisalarga qarshi samarali yondashuv avtonom javobga o'tishdir. Javobni avtomatlashtirish albatta yangi emas, ammo qo'rquv har doim noto'g'ri choraning oqibatlari haqida bo'lgan, bu esa rahbarni tizimdan chiqarib yuborishi yoki ishlab chiqarish integratsiyasini buzishi mumkin.

Biz choralarni ishqalanish bo'yicha saralash yaxshiroq deb topdik: noto'g'ri javob chorasi ma'lumot egasiga qancha turadi? Agar bu ularga yangi kirish yoki qayta ro'yxatdan o'tgan telefon turadigan bo'lsa, chora past ishqalanishli va yuqori ishonchli topilma bo'yicha ishga tushishi mumkin. Bu sessiyalarni bekor qilish, belgilangan sessiya davomida ro'yxatdan o'tgan MFA usulini olib tashlash va qayta yoqilishi mumkin bo'lgan kalitni o'chirishni o'z ichiga oladi.

Parolni qayta o'rnatish, hisobni o'chirish, doimiy o'chirish va ishlab chiqarish xizmati bog'liq bo'lgan har qanday narsa inson tasdiqlashini talab qilishi kerak. Inson maqsadli foydalanuvchi va uning rahbari bo'lishi mumkin, ular tezkor xabarda kirish ularning emasligini tasdiqlaydilar.

Muhokama qilingan choralar asosan shaxs yoki uning ma'lumotlari bilan bog'liq bo'lsa-da, ular shaxsni tasdiqlovchi provayder bilan cheklanmasligi kerak. Foydalanuvchining Okta parolini qayta o'rnatish yoki uning Okta sessiyasini o'ldirish Microsoft 365, Google Workspace yoki GitHub allaqachon bergan tokenlarni bekor qilmaydi va SSO orqali boshlangan AWS va Snowflake sessiyalari ishlashda davom etadi.

Bizning vishing holatlarimizda, biz ma'lumot o'g'irlanishi foydalanuvchining IdP sessiyasi bekor qilinganidan keyin 44 daqiqadan 3 soatgacha davom etganini aniqladik va bir holatda hujumchining pochta qutisi qoidalari parol qayta o'rnatilgandan keyin ham saqlanib qoldi. Okta Universal Logout Google Workspace va Slack kabi ba'zi ilovalarga yetadi, ammo GitHub, Snowflake yoki AI model provayderlariga emas.

Har bir ilovaning bekor qilish choralarini oldindan qurish yaxshiroq, ular bilan birga ularni bajaradigan hisob bilan birga. Biz hodisa o'rtasida javob chorasi 403 xatosi bilan muvaffaqiyatsiz tugaganini kuzatdik, chunki hech kim kerakli ruxsatlarni bermagan edi.

Ushbu javoblarni har bir ma'lumot manbai uchun qurish qo'rqinchli bo'lishi mumkin. Biz eng muhim ma'lumotlaringizni saqlaydigan xizmatlardan boshlashni tavsiya qilamiz.

Samaradorlik: Google Workspace, Office 365, Box, Dropbox, Slack Bulut: AWS, GCP, Azure AI xizmatlari: Anthropic, OpenAI Ma'lumot: Snowflake, Databricks Kod: GitHub, GitLab

Boshlash uchun tavsiya etilgan past ishqalanishli javoblar va ularni qanday amalga oshirish:

OKTA

Chora: Okta bergan sessiyalar va OAuth tokenlarini bekor qilish API: DELETE /api/v1/users/{id}/sessions?oauthTokens=true Kerakli ruxsatlar: okta.users.read va okta.users.manage doiralari, shuningdek faqat okta.users.read va okta.users.lifecycle.clearSessions saqlaydigan maxsus admin roli

Chora: Hujumchining ham barcha foydalanuvchi omillarini qayta o'rnatish API: POST /api/v1/users/{id}/lifecycle/reset_factors Kerakli ruxsatlar: Xuddi shu doiralar, rolga okta.users.credentials.resetFactors qo'shilgan

Microsoft Entra ID

Chora: Yangilash tokenlari va sessiya cookie-fayllarini bekor qilish API: POST /users/{id}/revokeSignInSessions Kerakli ruxsatlar: User.RevokeSessions.All, shuningdek foydalanuvchini qidirish uchun User.Read.All

Chora: Hujumchining ham foydalanuvchining MFA usullarini o'chirish API: Har bir telefon, Authenticator ilovasi, dasturiy OATH, FIDO2, Windows Hello va Vaqtinchalik Kirish Ruxsatnomasi usuli uchun DELETE /users/{id}/authentication/{type}Methods/{methodId} Kerakli ruxsatlar: UserAuthenticationMethod.ReadWrite.All, shuningdek User.Read.All

Google Workspace

Chora: Veb va qurilma sessiyalarini tugatish va ilovaning OAuth tokenlarini bekor qilish API: POST /admin/directory/v1/users/{userKey}/signOut, DELETE /admin/directory/v1/users/{userKey}/tokens/{clientId} Kerakli ruxsatlar: admin.directory.user.security doirasi, shuningdek vakolatli admin roli

GitHub Enterprise Cloud, tashkilot darajasidagi SAML SSO

Chora: Tashkilotdan o'g'irlangan tokenni o'chirish API: Uni topish uchun GET /orgs/{org}/credential-authorizations?login={user}, keyin DELETE /orgs/{org}/credential-authorizations/{credential_id} Kerakli ruxsatlar: admin:org bilan tashkilot egasi yoki tashkilot Ma'muriyati (yozish) bilan GitHub App. Kengroq variant yo'q

Snowflake

Chora: Dasturiy kirish tokenini o'chirish API: O'zingizning SQL'ingiz, masalan ALTER USER {name} MODIFY PAT {token} SET DISABLED TRUE, SQL API POST /api/v2/statements orqali yuboriladi Kerakli ruxsatlar: Foydalanuvchida MODIFY PROGRAMMATIC AUTHENTICATION METHODS roliga ega maxsus xizmat foydalanuvchisi

AWS

Chora: IAM foydalanuvchiga allaqachon berilgan STS sessiyalarini tugatish API: Hozirgacha berilgan sessiyalarda (aws:TokenIssueTime) inkor qiluvchi ichki siyosat bilan PutUserPolicy Kerakli ruxsatlar: iam:PutUserPolicy, shuningdek iam:GetUser va iam:GetUserPolicy

Anthropic

Chora: API kalitini o'chirish API: POST /v1/organizations/api_keys/{id} {"status":"inactive"} bilan Kerakli ruxsatlar: Admin API kaliti

Exaforce ushbu hujumlarni qanday hal qildi

Exaforce ixtiyoriy MDR xizmati bilan Agentic SOC platformasidir

Machine speed attacks require machine speed detection and response

Sponsored by Exaforce

October 22, 2026

10:02 AM

0

TL;DR: Our analysis shows attackers are now enumerating or pulling data within 15 minutes of getting into an environment, and the tools that should have caught them were not effective. We will discuss three common attack patterns in which we observed this behavior.

Stolen developer tokens. Poisoned npm packages and infostealers pull GitHub tokens from developer laptops; attackers later use those tokens to exfiltrate data from GitHub. GitHub has no native detections for how a token is used, leaving enterprises vulnerable to code exfiltration

ClickFix lures for AI tools. Fake Claude Code install commands in shared Claude chats load a macOS stealer that takes browser cookies and cloud credentials. The victim runs the commands themselves, much like they would when installing any tool, which may or may not trigger an endpoint detection.

Help desk vishing. Attackers leverage social engineering and pose as IT to get an employee to approve a real MFA prompt on a look-alike sign-in page. Identity providers can treat the attacker's login as legitimate, making them ineffective at detecting these issues.

Catching these incidents takes detection built on data and behavior. Stopping them takes an autonomous response. We cover both of these topics.

In March, a developer installed GitHub Desktop, signed in, and stopped using it the same day. The OAuth token it created sat in the Mac's keychain for 95 days. On June 19, someone else started using it.

The token pulled 76 repositories in about 15 seconds through residential proxies in more than two dozen European cities. GitHub raised no alert because nothing in GitHub watches how tokens are used. The Exaforce platform flagged it within five minutes and had it triaged within 10 minutes.

Our MDR analysts confirmed the exfiltration and notified the customer minutes after the detection fired. But by the time any action was taken, the attacker had exfiltrated data from 472 of the 638 repos.

This case shows both halves of the problem. Without anomaly detection, nobody would have known the token was in use. With proper detection in place, containment would still have required human approval, giving the attacker sufficient time to exfiltrate data.

Sleeper tokens on developer laptops

GitHub's security features are focused on inspecting code and secrets, not token misuse.  We caught this GitHub token compromise by stacking weak signals on a single GitHub session. Sign-ins to the account came from networks and cities never seen before.

It was pulling ZIP archives at machine speed, with a Windows user agent, on an account that had only ever used macOS. Each of these signals can potentially be explained, but all of them combined are indicative of something malicious.

OAuth app tokens like this one, prefixed gho_ , don't expire, and GitHub revokes them on its own only after a year. In our testing, the organization's SSO page does not even list these tokens, and they are visible only through the CLI. Disabling the developer in the identity provider doesn't stop the token either.

Without SCIM, GitHub keeps honoring tokens until someone revokes them or removes the user from the org.

Developers using AI coding tools install npm packages and connect MCP servers all day, mostly outside the pipelines that security teams monitor, and worms like Shai-Hulud sweep a machine for GitHub and cloud tokens the moment a poisoned package is installed.

This happens before anything is committed, which is why scanning your repositories to determine whether a compromised npm package may have affected you is not sufficient.

ClickFix goes after AI tool installs

Stealing a token from the macOS keychain usually requires an infostealer that phishes for the login password.

The latest ClickFix lures leverage trust from AI tools. In one such incident, an employee who was searching for Claude Code install instructions landed on a shared Claude conversation with a one-line install command.

The command loads a macOS stealer (we did a deep analysis with indicators) that fakes a System Preferences prompt for the password, then copies the keychain, browser cookies, saved passwords, and cloud credentials.

Because the victim runs the command, email filtering and download controls are bypassed. The most effective approach to catching these types of attacks is an endpoint detection solution. Assessing the scope of the impact should involve a comprehensive analysis of all tokens/credentials minted by the user.

See How Exaforce Agents Contain Identity Attacks

A hijacked session gives an attacker access to every app your users sign in to.

Book a demo to see how Exaforce agents detect and contain identity attacks across your environment.

Request a Demo

Fake IT calls that end in stolen sessions

In the vishing cases we worked this year, the attacker registered their own MFA device and started a bulk download script 2.5 7 minutes after the victim approved the push. In one such case, the attacker exfiltrated 140,000 files and requested a ransom for the leaked data.

Most of these calls follow the help desk script commonly leveraged by the Scattered Spider group. A caller posing as IT sends the employee to a sign-in page with the company's name in the URL, such as the passkey-themed contoso.add-passkey[.]com in Microsoft's September write-up.

The page either relays the login through an adversaryin-the-middle AiTM) proxy, or the attacker guides the victim through a device-code sign-in.

One kit we took apart, hosted on oskeysetup[.]com, was written from scratch, so detections built for Evilginx and the other public kits are not going to be effective.

In most instances, we observed that detections from identity providers are ineffective because victims approve a real MFA prompt. In a July session hijack we worked on, Microsoft flagged the attacker's first sign-in as risky, then marked the risk remediated because the user had passed MFA. Within minutes, the stolen token was replayed from two other countries within one second, and Microsoft's later alerts raised the user's risk level.

Exaforce caught it by tying the Okta and Microsoft sign-ins together and checking them against the user's history: this was the account's first-ever sign-in from the United States, on a Linux device, and through a home ISP the account had never used. In these cases the earliest strong signal is usually a new MFA method from a device and network the user has never touched.

We also noticed that attackers target the same company through multiple employees, often using the same servers and domains.

Autonomous response actions

An effective approach to counter the incidents discussed so far is to move toward autonomous response. Automating response is certainly not new, but the fear has always been about the consequences of a wrong action that can lock out an executive or break a production integration.

We find it's better to sort actions by friction instead: how much would a mistaken response action cost the person who owns the credential? If it costs them a fresh sign-in or a re-enrolled phone, the action is low-friction and can fire on a high-confidence finding. That covers revoking sessions, removing an MFA method registered during the flagged session, and deactivating a key that can be switched back on.

Password resets, account disablement, permanent deletions, and anything a production service depends on should require human approval. The human can be the target user and their manager, confirming in a quick message that the sign-in wasn't theirs.

Although most of the actions discussed are related to an identity or its associated credentials, they cannot be limited to the identity provider. Resetting the user's Okta password or killing their Okta session doesn't revoke tokens that Microsoft 365, Google Workspace, or GitHub already issued, and AWS and Snowflake sessions started through SSO keep running.

In our vishing cases, we found that data exfiltration continued for between 44 minutes and 3 hours after the user's IdP session was revoked, and in one case the attacker's inbox rules survived a password reset. Okta's Universal Logout reaches some apps, like Google Workspace and Slack, but not GitHub, Snowflake, or the AI model providers.

It's best to build each application's revocation actions ahead of time, along with the account that runs them. We've watched a response action fail mid-incident with a 403 because nobody had granted the required permissions.

It may be daunting to build these responses for every source of data. We recommend starting with services that hold your most critical data.

Productivity: Google Workspace, Office 365, Box, Dropbox, Slack

Cloud: AWS, GCP, Azure

AI services: Anthropic, OpenAI

Data: Snowflake, Databricks

Code: GitHub, GitLab

Recommended low-friction responses to start with and how to implement them:

OKTA

Action: Revoke sessions and the OAuth tokens Okta issued

API: DELETE /api/v1/users/{id}/sessions?oauthTokens=true

Permissions it needs: okta.users.read and okta.users.manage scopes, plus a custom admin role holding only okta.users.read and okta.users.lifecycle.clearSessions

Action: Reset all of the user's factors, including the attacker's

API: POST /api/v1/users/{id}/lifecycle/reset_factors

Permissions it needs: Same scopes, with okta.users.credentials.resetFactors added to the role

Microsoft Entra ID

Action: Revoke refresh tokens and session cookies

API: POST /users/{id}/revokeSignInSessions

Permissions it needs: User.RevokeSessions.All, plus User.Read.All to look up the user

Action: Delete the user's MFA methods, including the attacker's

API: DELETE /users/{id}/authentication/{type}Methods/{methodId} for each phone, Authenticator app, software OATH, FIDO2, Windows Hello, and Temporary Access Pass method

Permissions it needs: UserAuthenticationMethod.ReadWrite.All, plus User.Read.All

Google Workspace

Action: End web and device sessions, and revoke the app's OAuth tokens

API: POST /admin/directory/v1/users/{userKey}/signOut, DELETE /admin/directory/v1/users/{userKey}/tokens/{clientId}

Permissions it needs: admin.directory.user.security scope, plus a delegated admin role

GitHub Enterprise Cloud, orglevel SAML SSO

Action: Delete the stolen token from the organization

API: GET /orgs/{org}/credential-authorizations?login= {user} to find it, then DELETE /orgs/{org}/credentialauthorizations/{credential_id}

Permissions it needs: Org owner with admin:org, or a GitHub App with org Administration (write). There's no narrower option

Snowflake

Action: Disable a programmatic access token

API: Your own SQL, such as ALTER USER {name} MODIFY PAT {token} SET DISABLED  TRUE, sent through the SQL API POST /api/v2/statements)

Permissions it needs: A dedicated service user whose role has MODIFY PROGRAMMATIC AUTHENTICATION METHODS on the user

AWS

Action: End the STS sessions already issued to an IAM user

API: PutUserPolicy with an inline deny on sessions issued before now (aws:TokenIssueTime)

Permissions it needs: iam:PutUserPolicy, plus iam:GetUser and iam:GetUserPolicy

Anthropic

Action: Deactivate an API key

API: POST /v1/organizations/api_keys/{id} with {"status":"inactive"}

Permissions it needs: Admin API key

How Exaforce handled these attacks

Exaforce is an Agentic SOC platform with an optional MDR service. Our agents Exabots) handle detection engineering, alert triage, investigations, threat hunting, and response. The agents work on a unified data platform that can act as your SIEM or work alongside your SIEM.

The platform comes with 800 AI/ML anomaly detections that help detect the types of incidents we described across critical Cloud, SaaS, Identity, Endpoint, and AI services. There are 100+ dynamic response actions that agents can execute, so you don't have to build and maintain them yourselves for all your critical services.

You can read about more similar incidents under our ExaFiles research blogs here.

Sponsored and written by Exaforce.