Skip to content

Phishing de consentimento de OAuth e revogación de permisos de aplicacións de terceiros maliciosos

Imaxina descubrir que un atacante está lendo activamente os teus correos electrónicos privados, descargando os teus documentos na nube, creando regras de reenvío silencioso da caixa de entrada ou publicando ligazóns de estafa desde a túa conta, incluso DESPOIS de cambiar o teu contrasinal a unha cadea aleatoria de 24 caracteres e activar a autenticación de dous factores de hardware (2FA / Passkeys). Como é que un atacante segue dentro da túa conta de Google Workspace, Microsoft 365, GitHub, Slack ou Discord sen coñecer o teu novo contrasinal nin activar unha única solicitude de 2FA? Porque foi vítima de phishing de consentimento de OAuth 2.0 (tamén coñecida como concesión de consentimento ilícito ou phishing de código de dispositivo). En lugar de enganarte para que escribas o teu contrasinal nunha páxina de inicio de sesión falsa, o atacante enviouche unha ligazón a un accounts.google.com ou login.microsoftonline.com pantalla de autorización preguntando se se nomeou unha aplicación "PDF Document Viewer," "eSign Security Check," "Zoom Meeting Recorder," ou "Mail Backup Assistant" podería ter permiso para "Ler, redactar, enviar e eliminar permanentemente todo o teu correo electrónico de Gmail" ou "Ter acceso total a todos os ficheiros aos que tes acceso."

No momento no que fixeches clic Allow ou Accept Nese cadro de diálogo xenuíno de Microsoft ou Google, o fornecedor de identidade emitiu ao servidor do atacante un criptográfico de longa duración OAuth Refresh Token (offline_access). Porque os tokens da API de OAuth 2.0 se autentican directamente contra as API REST/Graph de backend (graph.microsoft.com ou gmail.googleapis.com) de forma totalmente independente da túa sesión web humana, cambiar o teu contrasinal ou engadir 2FA moitas veces deixa as subvencións de aplicacións de terceiros maliciosas activas ao 100 por cento. Para bloquear definitivamente ao atacante, debes revogar manualmente a concesión da aplicación de terceiros, eliminar todos os tokens de acceso e actualización de OAuth emitidos e eliminar as portas traseiras creadas pola aplicación mentres tiña acceso á API.

Fai isto agora

  1. Comprende inmediatamente por que cambiar o teu contrasinal NON detivo o hacker: debes revogar o Third-Party App / OAuth Consent Grant dentro do portal de seguranza da túa conta. Cando fai clic Allow nunha pantalla de OAuth, crea un contrato de API de máquina a máquina persistente (Service Principal / OAuth App Token). Vai directamente á páxina Aplicacións e servizos de terceiros do teu provedor agora mesmo (myaccount.google.com/connections para Google, myapps.microsoft.com ou account.live.com/consent/Manage para Microsoft, github.com/settings/applications para GitHub) e fai clic en Eliminar acceso/Revogar en todas as aplicacións que non recoñezas nin confíes ao 100%.
  2. Se escribiu un código alfanumérico de 8 ou 9 caracteres microsoft.com/devicelogin, google.com/device, ou github.com/login/device durante unha chamada ou chat de phishing, revogue os dous Active Device Sessions E OAuth App Grants inmediatamente. Nun ataque de phishing por fluxo de código de dispositivo (RFC 8628), o atacante xera un código de sincronización de smart-TV/CLI no seu ordenador e enganache para que teclees ese código no real microsoft.com/devicelogin páxina. Escribir ese código dálle ao atacante un ** principalRefresh Token (PRT / Multi-Resource Refresh Token)** disfrazado de cliente nativo de Microsoft Office, Azure CLI ou Apple Internet Accounts.
  3. Despois de revogar a aplicación OAuth maliciosa, audita inmediatamente o teu correo electrónico Forwarding Rules, Inbox Filters, e Delegated Mailbox Access a través da IU de Graph/Gmail. Que é o primeiro que fai unha aplicación OAuth maliciosa no primeiro momento? 500 milliseconds despois de facer clic Allow? Usa o Mail.ReadWrite ou MailboxSettings.ReadWrite Ámbito da API para inxectar unha regra invisible da caixa de entrada do servidor que reenvía automaticamente todos os correos electrónicos entrantes de banco, criptografía ou restablecemento de contrasinal ao atacante e dirixe as respostas directamente ao teu Trash ou RSS Feeds carpeta (ver Conta de correo electrónico pirateada: regras de reenvío e recuperación).
  4. Comproba se a aplicación OAuth maliciosa rexistrou unha segunda aplicación OAuth de copia de seguridade, o token de acceso persoal (PAT), clave SSH ou método MFA mentres tiña ámbitos administrativos. En Microsoft Entra ID (Azure AD), GitHub e Google Workspace, unha aplicación concedeu ámbitos de xestión de directorios ou contas (Application.ReadWrite.All, RoleManagement.ReadWrite.Directory, ou GitHub admin:public_key) pode crear silenciosamente un segundo token de API oculto ou principal de servizo para que o atacante conserve o acceso despois de eliminar a primeira aplicación.
  5. Se isto ocorreu nunha empresa ou escola Microsoft 365 ou Google Workspace conta, chama ao teu servizo de asistencia de TI/SOC en 5 minutos. Un só empregado fai clic Accept nunha ligazón de phishing de OAuth pode conceder a un atacante acceso de lectura a SharePoint, OneDrive, chats de Teams e Lista global de enderezos de toda a empresa, lanzando un compromiso interno de correo electrónico empresarial (BEC) ataque de fraude telefónico contra os seus compañeiros de traballo e clientes.
  6. Se o atacante usou o acceso OAuth para ver as túas unidades na nube (Google Drive / OneDrive), as declaracións de impostos, as exportacións de contrasinais ou os estados financeiros, conxela os teus ficheiros de crédito e bloquea as contas financeiras. Se na unidade de nube á que accedeu a aplicación OAuth se almacenaron documentos de identidade confidenciais ou frases de semente ou contrasinais sen cifrar, trata todos os ficheiros desa unidade como os descargados polo atacante (consulta Resposta á violación de datos e fugas de contrasinais).
flowchart TD
    A["Sospeita de phishing de consentimento de OAuth ou intrusión persistente na conta despois do restablecemento do contrasinal"] --> B["1. Abre o portal de permisos de aplicacións de terceiros (Google Connections/Microsoft MyApps/GitHub Applications)"]
    B --> C["2. Captura de pantalla aplicacións descoñecidas para obter probas e, a continuación, fai clic en 'Revogar/Eliminar acceso' en cada aplicación OAuth sospeitosa"]
    C --> D{"Introduciches un código nunha páxina de inicio de sesión do dispositivo (por exemplo, microsoft.com/devicelogin)?"}
    D -->|"Si: código de dispositivo phishing (RFC 8628)"| E["Execute 'Pechar sesión en todas partes/Revogar todos os tokens de actualización' para matar as sesións nativas de CLI/Código de dispositivo"]
    D -->|"Non: Concesión estándar de OAuth Web"| E
    E --> F["3. Auditoría e eliminación de portas traseiras secundarias creadas polo token API"]
    F --> G["Comproba as regras da caixa de entrada do correo electrónico, o reenvío automático e o acceso delegado (Gmail/Outlook)"]
    F --> H["Comprobe os tokens de acceso persoal do programador (PAT), as claves SSH e as integracións de webhook"]
    F --> I{"Esta era unha conta corporativa de Microsoft 365/Google Workspace?"}
    I -->|"Si"| J["Avise inmediatamente ao administrador da empresa/SOC para revogar a subvención de ServicePrincipal en Entra ID/Administrador do espazo de traballo"]
    I -->|"Non (Conta persoal)"| K["Cambiar contrasinal + Verificar dispositivos MFA + Comprobar os rexistros de actividade de descarga de Cloud Drive"]

Como o phishing de consentimento de OAuth 2.0 evita os contrasinais e 2FA (anatomía técnica)

Por que os sindicatos cibercriminais, os grupos de espionaxe nacionais (Midnight Blizzard, Star Blizzard), e os drenadores de criptomoedas pasaron moito do tradicional phishing de inicio de sesión falso a OAuth Consent Phishing e Device Code Phishing?

1. Phishing tradicional vs. Phishing por consentimento de OAuth vs. Phishing do código do dispositivo

Vector de ataque O que a vítima ve e fai clic Por que o antivirus, as claves de acceso e as comprobacións de URL do navegador fallan ao detelo Como o atacante mantén a persistencia
1. Credencial clásica/phishing AiTM (Cuberto en MFA phishing e bypass AiTM) A vítima fai clic nun dominio falso (login-micros0ft-support.com) e escribe o seu nome de usuario, contrasinal e código MFA de 6 díxitos. Detido ao 100 % por Fido2/WebAuthn Passkeys e Hardware Security Keys (YubiKey), que vinculan criptograficamente a autenticación ao nome de dominio real. Cookie de sesión de navegador robada (ESTSAUTH / SID), que morre en canto o usuario fai clic en "Pechar sesión en todas partes" ou restablece o seu contrasinal.
2. Concesión de consentimento da aplicación OAuth 2.0 maliciosa (Illicit Consent Phishing) A vítima fai clic nunha ligazón que os leva ao 100 % auténtico accounts.google.com ou login.microsoftonline.com dominio. Dado que o usuario xa iniciou sesión (ou inicia sesión coa súa clave de acceso/YubiKey real no dominio real), aparece unha caixa de permisos: "A aplicación [DocuSign Viewer] quere acceder á súa conta -> [Permitir]." Omite as claves de acceso e 2FA por completo. Porque o URL da barra de enderezos é lexítimo google.com ou microsoft.com, o teu navegador, o teu xestor de contrasinais e YubiKey autenticaránche con gusto e, a continuación, fai clic voluntariamente Allow para entregar un token de API ao OAuth rexistrado do atacante client_id. O fornecedor de identidade envía un authorization_code ao do atacante redirect_uri, que o atacante troca por un Access Token (1 hour) máis un OAuth Refresh Token (offline_access) que se mantén válido durante meses ou indefinidamente, sobrevive aos cambios de contrasinal en moitas plataformas.
3. OAuth 2.0 Device Authorization Grant Phishing (RFC 8628 Fluxo do código do dispositivo) O atacante envía un correo electrónico, unha mensaxe de Teams ou un código QR dicindo: "Para ver este documento de recursos humanos seguro/únete a esta reunión, abre https://microsoft.com/devicelogin e introduce o código B7X-99K-2PL." De novo, microsoft.com/devicelogin é o URL oficial e real de Microsoft (deseñado para iniciar sesión en Apple TV, Xbox e ferramentas de liña de comandos sen teclado). Non hai ningún dominio malicioso para bloquear un firewall. No momento en que tecleas B7X-99K-2PL e fai clic Continue, Microsoft vincula a túa sesión autenticada directamente ao terminal en espera do atacante (Token Endpoint polling), outorgándolle ao atacante un principal completo Refresh Token como unha aplicación de confianza propia (Microsoft Office ou Azure CLI).

2. Solicitude dos atacantes de ámbitos de permiso OAuth de alto perigo

Cando inspecciones unha aplicación na túa lista de permisos, mira detidamente os ámbitos que solicitou: * Microsoft Graph (Entra ID / Microsoft 365 / Outlook.com): * Mail.Read, Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite (Permite ler todos os correos electrónicos, enviar correos electrónicos como ti e crear regras ocultas de reenvío da caixa de entrada). * Files.Read.All, Files.ReadWrite.All, Sites.ReadWrite.All (Permite descargar todos os ficheiros do teu OneDrive e todos os cartafoles corporativos compartidos de SharePoint). * offline_access (Permite que o servidor do atacante acuña en silencio novos tokens de acceso 24 horas ao día, 7 días ao día, mesmo cando o ordenador estea apagado). * Directory.ReadWrite.All, AppRoleAssignment.ReadWrite.All, User.ReadWrite.All (Ámbitos de escalada de privilexios empresariais catastróficos). * Google Workspace/Gmail persoal (Google APIs): * https://mail.google.com/ ou gmail.modify / gmail.settings.basic / gmail.settings.sharing (Control total sobre a lectura, eliminación e reenvío de Gmail). * https://www.googleapis.com/auth/drive (Acceso completo de lectura/escritura/descarga a todos os ficheiros do teu Google Drive). * https://www.googleapis.com/auth/cloud-platform (Control total sobre a infraestrutura e a facturación de Google Cloud). * GitHub e ecosistemas de programadores (GitHub Apps / OAuth Apps): * repo e workflow (Acceso total de lectura/escritura a todos os repositorios privados de código fonte e permiso para inxectar canalizacións de roubo de segredos CI/CD de accións GitHub maliciosas). * admin:org, admin:public_key, e admin:gpg_key (Permiso para engadir chaves SSH de porta traseira persistentes ou modificar a pertenza da organización). * Ámbitos de OAuth de Slack e Discord: * Folla channels:history, groups:history, im:history, files:read, e chat:write (Permite que unha aplicación externa lea todas as mensaxes privadas directas do equipo, raspe os PDF e as credenciais cargados e envíe ligazóns de phishing facéndose pasar por un compañeiro de traballo de confianza). * Discordia guilds.join e identify (Permite que un bot ou portal de verificación comprometido unirse á súa conta de Discord aos servidores de estafa repetidamente sen o seu consentimento).

Fase 1: revogación paso a paso de aplicacións de OAuth e de terceiros para todas as plataformas principais

Sigue os pasos exactos que se indican a continuación para cada conta onde fixeches clic nunha ligazón sospeitosa, utilizaches "Iniciar sesión con Google/Microsoft/Apple/GitHub/Discord" nun sitio non fiable ou observaches actividade non autorizada.

1. Conta de Google (Personal Gmail & Google Workspace)

  1. Abre un navegador e vai directamente a: https://myaccount.google.com/connections (ou vai a myaccount.google.com -> fai clic en Seguridade no menú da esquerda -> desprázate ata As túas conexións con aplicacións e servizos de terceiros -> fai clic en Ver todas as conexións).
  2. Filtrar por risco: Fai clic no chip de filtro na parte superior etiquetado Access to your Google Account (que filtra os inicios de sesión inofensivos de "Iniciar sesión con Google" só por nome e destaca as aplicacións que teñen permisos de API activos para ler o teu Gmail, Google Drive, Calendario ou Contactos).
  3. Fai clic en todas as aplicacións descoñecidas, sospeitosas ou que xa non se usan (coidado cos nomes enganosos que imiten utilidades do sistema como "Google Docs Viewer," "PDF Converter," "Email Cleaner," "eFax," ou "Drive Backup").
  4. Desprácese ata Ver detalles para ver a data e a hora exactas en que se concedeu o acceso e os ámbitos (Gmail, Google Drive) aguanta.
  5. Fai clic Delete all connections you have with [App Name] -> Fai clic en Confirmar.
  6. Revoga tamén sesións activas do dispositivo (para phishing do código do dispositivo): Vaia a https://myaccount.google.com/device-activity e pecha sesión en calquera sesión de dispositivos Linux, Windows, Mac ou Smart TV que non se familiarice.

2. Microsoft Persoal (Outlook.com / Hotmail / Live / Xbox) vs. Corporativo (Microsoft 365 / Entra ID)

Microsoft usa dous portais diferentes dependendo de se a súa conta é unha conta persoal de consumidor ou unha conta de traballo ou escola:

A. Contas persoais de Microsoft (@outlook.com, @hotmail.com, @live.com)

  1. Ir directamente a: https://account.live.com/consent/Manage (ou vai a account.microsoft.com/privacy -> Aplicacións e servizos que poden acceder aos teus datos).
  2. Inspeccione cada aplicación listada. Se ves algunha aplicación que non recoñezas (ou un cliente que soe lexítimo como eM Client, Thunderbird, ou Mail App que nunca instalaches ti mesmo, un truco común que usan os atacantes para obter tokens IMAP/Graph OAuth), fai clic en Edit baixo esa aplicación e fai clic en Remove these permissions.
  3. A continuación, vai a https://account.microsoft.com/security -> Xestionar como inicio sesión -> desprázate cara abaixo e fai clic en Sign me out (o que obriga a unha invalidación global en todos os navegadores, aplicacións e sesións de Xbox/OneDrive nun prazo de 24 horas).

B. Corporativo / Traballo / Escolar Microsoft 365 & Microsoft Entra ID (Azure AD)

  1. Como usuario empregado individual:
  2. Ir a https://myapps.microsoft.com -> Fai clic na icona do teu perfil ou na icona da engrenaxe -> Fai clic en Perfil ou fai clic nos tres puntos (...) en calquera mosaico de aplicacións descoñecidas -> Seleccione Xestionar a súa aplicación -> Revogar permisos.
  3. Tamén vai a https://myaccount.microsoft.com -> Información de seguranza -> verifique que non se engadiu ningunha aplicación Authenticator non autorizada e prema en Sign out everywhere na pestana Visión xeral.
  4. Como administrador de Microsoft 365 / Entra ID (token de emerxencia PowerShell e purga de consentimento): Cando un empregado cae en phishing de consentimento de OAuth ou phishing de código de dispositivo nun inquilino empresarial, simplemente eliminar a aplicación do portal MyApps do usuario non é suficiente; un administrador debe revogar o OAuth2PermissionGrant en todo o inquilino e invalidar o do usuario RefreshTokensValidFromDateTime a través de Microsoft Graph PowerShell:
# Connect to Microsoft Graph with Directory & Delegated Permission Grant Administrator privileges:
Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All", "DelegatedPermissionGrant.ReadWrite.All", "Application.ReadWrite.All"

# 1. Inspect all OAuth2 Delegated Permission Grants for the compromised user:
$User = Get-MgUser -UserId "victim@yourdomain.com"
Get-MgUserOauth2PermissionGrant -UserId $User.Id | Format-List Id, ClientId, ConsentType, Scope, ResourceId

# 2. Immediately delete the malicious OAuth2PermissionGrant by its Grant Id:
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<Grant-ID-From-Step-1>"

# 3. Remove the malicious Enterprise Application (ServicePrincipal) from the entire tenant so no other employee is affected:
Remove-MgServicePrincipal -ServicePrincipalId "<Malicious-ClientId-ObjectId>"

# 4. Revoke ALL active OAuth Refresh Tokens and Continuous Access Evaluation (CAE) sessions for the user immediately:
Revoke-MgUserSignInSession -UserId $User.Id

3. GitHub, Slack, Discord, Apple (Sign in with Apple), e X / Contas Sociais

Os atacantes apuntan en gran medida ás contas de programadores, comunidades e sociais con phishing de OAuth para impulsar as confirmacións de códigos maliciosos, drenar comunidades de Discord ou publicar ligazóns de eliminación de criptomoedas:

Plataforma URL directo para auditar e revogar aplicacións/fichas de OAuth Portas traseiras ocultas críticas para comprobar na mesma páxina
GitHub https://github.com/settings/applications Comprobe as TRES pestanas desa páxina: 1. Installed GitHub Apps,2. Authorized GitHub Apps, e 3. Authorized OAuth Apps. Entón verifica inmediatamente https://github.com/settings/tokens (Elimine calquera tipo de gran fino ou clásico Personal Access Tokens) e https://github.com/settings/keys (Elimine as chaves SSH descoñecidas).
Discord Abre Configuración do usuario (icona de engrenaxe) -> Aplicacións autorizadas Busca calquera bot ou aplicación que teña concedido o perigo Join servers for you (guilds.join), Access your email address ou Read messages ámbito. Fai clic no botón vermello Desautorizar en cada entrada descoñecida.
Foxo Aberto https://my.slack.com/apps/manage (Directorio de aplicacións de Workspace -> Xestionar) Busca Webhooks entrantes, Comandos Slash ou aplicacións OAuth de terceiros que teñan instaladas recentemente channels:history, files:read, ou chat:write ámbitos e fai clic en Eliminar aplicación.
ID de Apple (Sign in with Apple) iPhone: Settings -> [Your Name] -> Sign-In & Security -> Sign in with Apple
Web: appleid.apple.com -> Sign-In and Security -> Sign in with Apple		 Selecciona calquera aplicación ou sitio web descoñecido e toca Stop Using Apple ID.
X (Twitter) / Meta (Facebook / Instagram) / LinkedIn X: Settings and privacy -> Security and account access -> Apps and sessions -> Connected apps
Facebook: Settings -> Apps and websites		 Cando unha conta de X/Twitter ou Instagram verificada publica de súpeto unha estafa de envío de criptomonedas ou de sorteo falso sen que se cambie o contrasinal do propietario, o 95 % das veces é unha Aplicación OAuth conectada con Read and Write permisos. Fai clic en Revogar permisos da aplicación inmediatamente.

Fase 2: busca de persistencia secundaria deixada pola aplicación OAuth maliciosa

Danger

A revogación da aplicación OAuth detén as chamadas API futuras desa aplicación, pero NON desface as trampas que a aplicación xa puxo na túa conta mentres tiña acceso. Kits de phishing de OAuth automatizados (EvilProxy, Tycoon 2FA, scripts de gráficos personalizados) executa un script posterior á explotación en 2 segundos desde a recepción do seu token OAuth. Debes comprobar as cinco localizacións de persistencia despois de revogar a aplicación:

1. Regras da caixa de entrada de correo electrónico, reenviadores automáticos e regras de varrido oculto (Gmail & Outlook / M365)

Se a aplicación OAuth maliciosa tiña Mail.ReadWrite ou MailboxSettings.ReadWrite permisos: * En Gmail: fai clic na icona da engrenaxe (arriba á dereita) -> Ver todas as opcións. 1. Fai clic no Forwarding and POP/IMAP pestana -> Comproba iso Forwarding está definido como Desactivar o reenvío e non aparece ningún enderezo de correo electrónico descoñecido. 2. Fai clic no Filters and Blocked Addresses pestana -> Busca calquera filtro que coincida from:(*) ou palabras clave como bank, wire, invoice, coinbase, password, ou security coa acción Delete it,Skip the Inbox (Archive it) ou Forward it to -> Elimina eses filtros inmediatamente. 3. Fai clic no Accounts and Import pestana -> En Conceder acceso á túa conta (Acceso delegado) e Enviar correo como, elimina calquera enderezo descoñecido. * En Microsoft Outlook Web (outlook.office.com ou outlook.live.com): Fai clic na icona da engrenaxe (arriba á dereita) -> Correo. 1. Fai clic Rules -> Elimina todas as regras descoñecidas (os atacantes adoitan nomear regras maliciosas . ou ... ou Security Sync e configúraos para mover os correos electrónicos entrantes ao RSS Subscriptions ou Conversation History cartafol mentres os marca como Ledos). 2. Fai clic Forwarding (e Junk email) -> Asegúrate de que Activar o reenvío estea desmarcada e elimina calquera dominio do atacante engadido á lista de Remitentes e dominios seguros.

2. Auditoría de descarga masiva de Cloud Drive e portas traseiras de "Compartición de ligazóns" (Google Drive & OneDrive / SharePoint)

Unha vez que teña unha aplicación OAuth Files.ReadWrite.All ou drive alcance, fai dúas cousas: en primeiro lugar, descarga os teus PDF sensibles, follas de cálculo e ficheiros de contrasinais; en segundo lugar, pode cambiar silenciosamente os permisos de uso compartido dos teus cartafoles confidenciais a "Anyone with the link can view/edit" polo que o atacante aínda pode abrir eses cartafoles nun navegador anónimo mesmo despois de revogar a aplicación OAuth. * En Google Drive: Fai clic no (i) Icona Ver detalles (actividade) na esquina superior dereita para ver todos os ficheiros vistos, modificados ou compartidos nos últimos 7 días. Despois escribe is:unorganized,sharedwith:public ou sharedwith:external na barra de busca superior de Google Drive para atopar os ficheiros ou cartafoles que o atacante fixo accesibles ao público. * En Microsoft OneDrive: vai á pestana Compartido -> Compartido por ti no menú da esquerda e revoga calquera ligazón pública (Anyone with the link) non creaches.

3. Google Apps Script (script.google.com) & Microsoft Power Automate (make.powerautomate.com) Disparadores

Aquí tes un truco de persistencia usado contra usuarios de Google e Microsoft 365: mentres está dentro da túa conta, un atacante crea un Script de Google Apps de 10 liñas (en https://script.google.com/home/triggers) ou un Microsoft Power Automate Cloud Flow (en https://make.powerautomate.com) configurado para funcionar cun temporizador de 5 minutos (Time-driven trigger ou When a new email arrives). Debido a que ese script execútase de forma nativa dentro da túa propia conta na nube, segue filtrando os teus correos electrónicos cada 5 minutos mesmo despois de que cambies o contrasinal e elimines aplicacións externas. * Aberto https://script.google.com/home/triggers (para Google) ou https://make.powerautomate.com -> Os meus fluxos (para Microsoft 365) agora mesmo e elimina calquera script ou fluxo automatizado que non escribiu persoalmente.

4. Auditoría dos rexistros de auditoría da nube para a exfiltración de datos (Google Takeout, Entra Sign-In Logs, & Unified Audit Log)

Se precisa saber exactamente que correos electrónicos ou ficheiros leu ou descargou a aplicación OAuth maliciosa mentres o seu token estaba activo: * En contas persoais de Google: Abrir https://myactivity.google.com e https://myaccount.google.com/notifications para inspeccionar eventos de seguranza recentes e comprobar se se solicitou unha exportación de arquivo de Google Takeout. * En Google Workspace (Consola de administración): Vai a admin.google.com -> Reporting -> Audit and investigation -> OAuth log events e Drive log events filtrado polo usuario comprometido e o malintencionado Client ID para obter unha lista completa con marca de tempo de cada ID de ficheiro ao que se accede. * En Microsoft 365 (Purview / Entra ID): Aberto entra.microsoft.com -> Identity -> Monitoring & health -> Sign-in logs, fai clic no Non-interactive user sign-ins e Service principal sign-ins pestanas (os rexistros de inicio de sesión interactivo estándar NON mostran as actualizacións do token OAuth en segundo plano) e filtran polo malicioso Application ID para ver cada enderezo IP e chamadas de recursos realizadas polo atacante.

5. Rotando os segredos expostos atopados dentro da túa unidade na nube ou correo electrónico

Se a aplicación OAuth maliciosa tivo acceso aos teus repositorios de Gmail, Outlook, Google Drive, OneDrive ou GitHub durante 60 segundos, supoña que o atacante executou un raspador automático de expresións regulares na túa caixa de correo e unidade buscando: 1. Frases sementes de criptomoeda (12/24-word BIP-39 mnemonics) ou Wallet .json Almacéns de claves: Se unha foto ou documento que contén unha frase semente criptográfica estaba na túa unidade de nube ou correo electrónico, move todos os fondos a unha nova carteira de hardware inmediatamente (consulta Drenaxe de carteira de criptomoedas e compromiso de frase semente). 2. Xestor de contrasinais exportado .csv Expedientes ou declaracións de impostos (Form 1040 / W-2): Xira os teus contrasinais e conxela as túas axencias de crédito (Equifax, Experian, TransUnion) inmediatamente. 3. Chaves da API do programador (AWS_SECRET_ACCESS_KEY, Stripe, OpenAI, GitHub PATs, .env ficheiros): Revoga e rola todos os segredos da infraestrutura na nube que apareceron nos teus correos electrónicos, mensaxes de Slack ou documentos na nube.

Lista de verificación de prevención: deter permanentemente o phishing de código de dispositivo e OAuth

  • Nunca concedas unha aplicación externa completa Read/Write Email ou Full Cloud Drive permisos só para ver un único PDF, invitación de calendario ou utilidade: Unha ligazón lexítima de visualización de documentos nunca necesita permiso para "Ler, redactar, enviar e eliminar permanentemente todo o teu correo electrónico de Gmail." Se unha pantalla de consentimento de OAuth inesperada pide unha caixa de correo ampla ou ámbitos de unidades, pecha a pestana inmediatamente.
  • Nunca escriba a Device Login Code (microsoft.com/devicelogin ou google.com/device) enviada por outra persoa nun correo electrónico, texto ou chat: Códigos de dispositivo (RFC 8628) son estrictamente para pantallas de hardware sentados fisicamente diante de ti na mesma habitación (como a túa propia sala de estar Apple TV ou o teu propio terminal SSH). Se outra persoa xera un código de dispositivo e che pide que o escribas, estás iniciando sesión o seu ordenador na súa conta.
  • Para administradores de Microsoft 365/Google Workspace: desactive o consentimento da aplicación OAuth do usuario final e bloquee o fluxo de código do dispositivo mediante o acceso condicional:
  • En Microsoft Entra Admin Center (entra.microsoft.com) -> Identidade -> Aplicacións -> Aplicacións empresariais -> Consentimento e permisos -> Configuración de consentimento do usuario, cambia de Permitir o consentimento do usuario para aplicacións a Do not allow user consent (e activa o Fluxo de traballo de consentimento do administrador para que os empregados fagan clic en "Solicitar aprobación" en lugar de conceder acceso a aplicacións non autorizadas).
  • Na Consola de administración de Google Workspace (admin.google.com) -> Seguridade -> Acceso e control de datos -> Controis da API -> Xestionar o acceso a aplicacións de terceiros, establecer ámbitos de alto risco (Gmail, Drive) a Trusted: Can only access Google data if explicitly allowlisted by an admin.
  • Crea unha Política de acceso condicional de ID de entrada que bloquee o Device Code Flow Método de transferencia de autenticación para todos os usuarios que non sexan programadores.

Preguntas frecuentes

Por que non cambiar o meu contrasinal e activar a autenticación de dous factores (2FA) expulsou unha aplicación OAuth maliciosa?

Os contrasinais e a autenticación de dous factores só protexen a porta principal cando un humano inicia sesión a través dunha pantalla de inicio de sesión. Cando fai clic `Allow` nunha solicitude de consentimento de OAuth 2.0, indicas a Google, Microsoft, GitHub ou Discord que emitan un código criptográfico `Refresh Token` directamente ao servidor desa aplicación de terceiros para que a aplicación poida funcionar en segundo plano mentres estás sen conexión. Por deseño arquitectónico, moitas plataformas permiten que as integracións de terceiros autorizadas (como ferramentas de sincronización de calendario, servizos de copia de seguranza ou conectores CRM) sigan funcionando con rotacións rutineiras de contrasinais a menos que accedas explícitamente á páxina de conexións de aplicacións de terceiros e fagas clic en **Revogar/Eliminar acceso**.

Como se pode mostrar unha ligazón de phishing de OAuth accounts.google.com ou login.microsoftonline.com cun candado HTTPS real se fose unha estafa?

Nun ataque de phishing por consentimento de OAuth, o criminal non crea un sitio web falso; en cambio, rexistran unha aplicación gratuíta para desenvolvedores dentro de Google Cloud ou Microsoft Azure (o que leva 2 minutos) e envíache unha ligazón de autorización de Google ou Microsoft xenuína que contén a súa aplicación. `client_id`. Como estás visitando o servidor de inicio de sesión real de Google ou Microsoft, o nome de dominio e o certificado SSL son 100 por cento auténticos. O engano está en **quen é o propietario do nome da aplicación de terceiros** que pide permiso unha vez que inicie sesión; facendo clic `Allow` dille ao servidor real de Google ou Microsoft que entregue os teus datos á aplicación de programador rexistrada do criminal.

Que é o "Código do dispositivo Phishing" (microsoft.com/devicelogin), e por que é tan perigoso?

A concesión de autorización de dispositivos OAuth 2.0 (`RFC 8628`) creouse para que puideses iniciar sesión en dispositivos que non teñen un navegador web ou teclado, como un Smart TV ou unha interface de liña de comandos (CLI): o televisor mostra un código de 8 caracteres e indica que o abras. `microsoft.com/devicelogin` no teu teléfono e introduce ese código. Nun ataque de phishing de código de dispositivo, un hacker executa un script (`TokenTactics` ou `RoadTools`) no seu propio ordenador para xerar un código novo de 8 caracteres, despois envíache correos electrónicos ou mensaxes en Teams/Slack dicindo que debes introducir ese código en `microsoft.com/devicelogin` para ver un documento seguro ou verificar a súa conta. No momento en que escriba o seu código no sitio real de Microsoft, Microsoft rexistra o ordenador do hacker directamente na súa conta coas reclamacións completas de autenticación multifactor xa satisfeitas.

É perigoso "Iniciar sesión con Google" ou "Iniciar sesión con Apple" estándar se a ventá emerxente só pide o meu nome e enderezo de correo electrónico?

Conexión OpenID estándar (`OIDC`) "Iniciar sesión con Google/Apple/Microsoft" indica que **só** solicita o teu perfil básico (`Name`, `Email address`, e `Profile picture`) son en realidade moito máis seguros que escribir un contrasinal nun sitio web novo, porque o sitio web de terceiros nunca ve o teu contrasinal e non ten acceso aos teus correos electrónicos ou ficheiros. O perigo só se produce cando a ventá emerxente de consentimento solicita **ámbitos de API sensibles adicionais**, como *"Ler, redactar, enviar e eliminar permanentemente todo o teu correo electrónico",* *"Ver, editar, crear e eliminar todos os teus ficheiros de Google Drive"* ou *"Únete aos servidores por ti."* Lea sempre a lista de permisos con viñetas antes de facer clic na pantalla de consentimento.

Guías relacionadas

Fontes comprobadas

  • Axencia de seguridade cibernética e de infraestruturas (CISA) e Federal Bureau of Investigation (FBI) (Estados Unidos): asesoramento conxunto de ciberseguridade sobre concesións de consentimento de OAuth ilícitos, phishing de código de dispositivo (RFC 8628) e Cloud Identity Token Theft.
  • Internet Engineering Task Force (IETF) (Internacional): RFC 6749 (The OAuth 2.0 Authorization Framework), RFC 7009 (OAuth 2.0 Token Revocation) e RFC 8628 (OAuth 2.0 Device Authorization Grant Security Considerations).
  • Microsoft Threat Intelligence e Microsoft Entra Security Engineering (internacional): Guía de xogos de resposta a incidentes para aplicacións OAuth maliciosas (OAuth2PermissionGrant) e Phishing do código do dispositivo en Microsoft Entra ID.
  • Google Cloud e Google Workspace Security (internacional): verificación do alcance da API de OAuth 2.0, goberno de acceso a aplicacións de terceiros e arquitectura de revogación de tokens.
  • National Cyber ​​Security Center (NCSC) (Reino Unido): Orientación sobre a defensa dos arrendatarios da nube contra o phishing de consentimento de OAuth e o abuso da API delegada.