Malware Umbrij, ligado à APT ToddyCat, abusa de OAuth e API do Google para roubo sigiloso de e-mails corporativos

Ameaça utiliza técnica de depuração remota em navegadores baseados em Chromium para sequestrar sessões ativas do Gmail e automatizar a concessão de tokens de acesso à infraestrutura do Google Workspace.

Componente	Malware Umbrij (.NET ofuscado com ConfuserEx), navegadores Chromium (Google Chrome, Microsoft Edge), Google API e protocolo OAuth 2.0.
Vetor	Inicialização do navegador em modo oculto (headless) seguida pela conexão via porta de depuração remota para automatizar cliques e fraudar o consentimento de permissões do Google Workspace.
Impacto	Comprometimento stealth de comunicações corporativas, permitindo acesso direto a e-mails e dados do Workspace através de tokens legitimados.
Prioridade	Remover acessos OAuth suspeitos nas configurações de conta do Google e monitorar processos de navegador iniciados em modo de depuração em estáções de trabalho.

Resumo técnico

O grupo de ameaça persistente avançada (APT) rastreado como ToddyCat foi associado ao desenvolvimento e implementação de uma nova ferramenta maliciosa denominada Umbrij. Análises detalhadas indicam que este malware foi projetado com um objetivo altamente focado: obter acesso oculto e contínuo às comunicações corporativas hospedadas no Gmail. A campanha demonstra uma evolução nas táticas do grupo, que anteriormente explorava ferramentas para exfiltrar dados do Microsoft Outlook, como o utilitário TCSectorCopy, e agora redireciona seus esforços para a infraestrutura em nuvem do Google.

O núcleo da operação reside no abuso do protocolo OAuth 2.0 e da interface de programação de aplicações do Google. Em vez de tentar quebrar senhas ou contornar mecanismos tradicionais de autenticação, os operadores conseguem fazer com que o navegador legítimo do usuário vitima conceda permissões amplas de acesso a aplicações maliciosas ou fraudadas. Ao obter o token de acesso, a comunicação com os recursos de e-mail ocorre por canais de API considerados confiáveis pelo ambiente de nuvem, reduzindo drasticamente a probabilidade de detecção por sistemas convencionais de prevenção de perda de dados ou monitoramento de tráfego de rede.

Fluxo técnico

A infecção e o estabelecimento do acesso são executados em fases metodológicas que evidenciam um profundo conhecimento da arquitetura do sistema operacional e dos navegadores modernos. A execução do payload original envolve a técnica de side-loading de DLL. Durante operações de threat hunting, descobriu-se que a infecção inicial pode ser disparada por uma tarefa agendada forjada, que utiliza um nome disfarçado de software de segurança legítimo (KasperskyEndpointSecurityEDRAvp). Essa tarefa aciona um arquivo digitalmente assinado que, por sua vez, carrega a biblioteca dinâmica maliciosa do Umbrij, escrita em.NET e protegida pelo ofuscador de código aberto ConfuserEx.

Uma vez em execução no host, o malware realiza ações preparatórias críticas para garantir que operará sob o contexto de usuário correto e colherá as informações locais necessárias. O malwareInicial localiza o processo explorer.exe em execução para duplicar seu token de acesso, assegurando que terá os privilégios da sessão ativa. Em paralelo, localiza diretórios de instalação e perfis de usuário de navegadores baseados em Chromium. Ele analisa os arquivos de estado local para enumerar perfis e identificar endereços de e-mail corporativos autenticados, indicando alvos em potencial.

A pivotação para o ambiente em nuvem ocorre através de uma técnica apelidada pelos pesquisadores de STRD (Shadow Token via Remote Debug). O malware verifica a disponibilidade de uma porta de depuração local, cria um diretório de backup falso (BackupFiles) e copia à força arquivos sensíveis do perfil do navegador, como bancos de dados de login, armazenamento local e parâmetros de rede. Utilizando a biblioteca Puppeteer, o atacante instrui o navegador a iniciar em modo headless (sem interface gráfica) e se conecta a ele através do protocolo Chrome DevTools.

Sob este controle total do navegador vitima, o malware automatiza o envio de requisições para o ponto de extremidade de autenticação OAuth do Google, utilizando um identificador de cliente que mimetiza ferramentas legítimas de migração de dados. A biblioteca Puppeteer é então usada para emular cliques de mouse em ambiente virtual, aprovando de forma invisível as telas de consentimento. Isso concede acesso total e silencioso a e-mails, Drive, Contatos, Calendário e Tarefas. O código de autorização gerado é interceptado, registrado em arquivos de log para exfiltração e posteriormente trocado por um token de acesso final, consolidando o comprometimento via Google API.

Superfície afetada

A arquitetura do ataque demonstra que qualquer estáção de trabalho comprometida com uma sessão ativa de navegador baseado em Chromium apresenta uma superfície de exposição crítica. Embora a camada de acesso初步 occur no sistema operacional, o alvo de valor primário reside na infraestrutura de identidade e colaboração em nuvem da organização. Funcionários que utilizam Google Workspace em ambientes corporativos estão diretmente vulneráveis a está técnica de abuso de token se o endpoint for comprometido por fases anteriores do ataque.

• Navegadores baseados em Chromium com sessões do Google ativas (perfis autenticados).
• Sistemas Windows onde arquivos legitimos suscetíveis a side-loading de DLL podem ser abusados (como componentes de testes ou indexação de arquivos).
• Contas corporativas do Google Workspace, expondo dados contidos no Gmail, Google Drive, Google Contacts, Google Calendar e Google Tasks.
• Infraestruturas onde o monitoramento de portas locais de depuração e processos headless não é realizado de forma ativa pelo endpoint detection and response.

Hunting e telemetria

Devido à natureza furtiva da operação, que abusa de binários assinados e protocolos considerados legítimos pelo sistema, as equipes de operações de segurança devem calibrar suas estratégias de busca. O monitoramento focado em anomalias comportamentais, relação de processos filhos e chamadas de rede inesperadas originadas de Processos ocultos é essencial para identificar a presença deste malware.

• MonitorarBinary a execução de determinados arquivos executáveis legítimos acompanhada da criação de bibliotecas dinâmicas não padrão no mesmo diretório (side-loading). alguns exemplos.Binary
• Rastrear o estabelecimento de conexões do navegador através do Chrome DevTools Protocol e o uso de ferramentas de controle do type Puppeteer fora de fluxos de desenvolvimento ou automação oficial.
• Inspecionar a criação forçada de pastas denominadas BackupFiles em paths locais de configuração de navegador, acompanhada da cópia não usual de arquivos como Login Data, Local Storage e Web Data.
• Buscar por instâncias onde processos de navegação de internet comunicam-se ativamente com endpoints de OAuth do Google de origem inesperada ou requerendo níveis anormais de permissão de acesso a leitura de API.
• Observar companyId a existência de tarefas agendadas criadas de forma não padronizada, especialmente as que referenciam nomes de softwares de cibersegurança consagrados para iniciar arquivos não nativos do sistema operacional.

Mitigação

A defesa contra o malware Umbrij exige uma postura hibrida que envolva estratégias de hardening de sistema local, monitoramento de fraude de consentimento de aplicações e resposta rápida em identidade em nuvem. Como os invasores utilizam aplicações que se passam por softwares de migração, a auditoria manual dessas permissões no painel de controle do usuário é uma etapa crítica de bloqueio.

• Inspecion proativamente as conexões de aplicações OAuth concedidas. Solicitar aos usuários corporativos e administradores que naveguem até o endereço myaccount.google[.]com/connections e avaliem as permissões existentes.
• Revogar imediatamente o acesso de aplicações que se identifiquem como Google Workspace Migration for Microsoft Outlook ou Google Workspace Sync for Microsoft Outlook, caso essas ferramentas não sejam oficialmente adotadas e autorizadas nos fluxos de trabalho da empresa.
• Implementar regras de aplicativo no sistema operacional ou nas configurações do EDR para bloquear a execução não autorizada de navegadores em modo de depuração remota ou o uso não previsto do protocolo Puppeteer fora de estáções de desenvolvedores autorizadas.
• Restringir a criação de tarefas agendadas a contas administrativas e aplicar políticas de controle de aplicativos para impedir que binários legitimos sejam usados para carregar bibliotecas não confiáveis a partir de locais graváveis pelo usuário.
• Adotar mentally uma postura de segurança zero trust no acesso à API da nuvem, necessitando validação contextual além da mera existência de tokens OAuth para operações de exportação de grande volume de dados corporativos.