Infostealer AMOS mira credenciais de nuvem no macOS

A Unit 42, divisão de pesquisa de ameaças da Palo Alto Networks, publicou em 16 de setembro de 2026 a dissecação de uma infecção do infostealer AMOS — abreviação de Atomic macOS Stealer — reproduzida em laboratório no dia 5 de agosto de 2026. O relatório é assinado pelo pesquisador Bradley Duncan e traz um retrato detalhado do comportamento do malware no disco, na memória e no tráfego de rede.

O que chama atenção não é a novidade da família, conhecida desde abril de 2024, mas o inventário do que ela levou. Além das carteiras de criptomoedas que consagraram esse tipo de praga, o arquivo compactado preparado para exfiltração continha diretórios dedicados a credenciais da AWS, do Google Cloud, do Docker e do FileZilla, além do histórico de comandos do shell. Em outras palavras: em uma máquina de desenvolvedor ou de pessoa de infraestrutura, o prejuízo não termina no Mac infectado.

O Plugged Ninja já tratou do AMOS em agosto de 2026, quando o vetor analisado era uma campanha ClickFix com filtragem de vítimas no servidor. A análise atual descreve um caminho de entrega diferente e artefatos de persistência que não apareciam naquele material, e por isso é tratada aqui como atualização do assunto.

O que é o AMOS e por que ele importa

O AMOS é um ladrão de informações voltado exclusivamente para o macOS, anunciado em canais do Telegram desde abril de 2024 e comercializado no modelo de malware como serviço. Ele não cifra arquivos nem pede resgate: seu objetivo é copiar dados sensíveis o mais rápido possível e enviá-los a um servidor de comando e controle.

Segundo a Unit 42, o malware representa uma fatia significativa das ameaças de roubo de dados em macOS e é considerado uma ameaça em crescimento. A distribuição observada até hoje passa por campanhas de ClickFix, por anúncios maliciosos e por sites que prometem versões pirateadas de programas pagos.

A entrega: um kit para macOS que não é ClickFix

A infecção analisada começou em getmacouscloud[.]com, uma página que oferecia instruções de configuração rápida para um suposto kit de ferramentas do macOS. A vítima copia um texto da página e cola em uma janela do Terminal.

A Unit 42 faz aqui uma distinção técnica que vale registrar, porque a imprensa costuma tratar tudo como a mesma coisa: isso não é ClickFix. A técnica ClickFix se apoia em uma falsa verificação — um CAPTCHA fake, por exemplo — que injeta um comando na área de transferência da vítima. No caso analisado, não há CAPTCHA nem verificação simulada; a página simplesmente apresenta o comando como parte de um tutorial de instalação. O efeito prático é o mesmo, mas o gatilho psicológico e os indicadores de detecção são distintos.

O comando colado baixa um script Zsh de ferncore13[.]com. Esse script carrega um bloco codificado com uma carga comprimida em GZIP, que por sua vez contém um segundo script Zsh responsável por buscar e executar um binário Mach-O — o instalador do AMOS, gravado como /tmp/helper.

Persistência disfarçada de componente da Apple

O ponto mais interessante da análise forense é a escolha dos nomes. O instalador cria dois diretórios ocultos dentro de ~/Library/Application Support/:

accountsd e mdworker são nomes de processos legítimos do macOS — o primeiro ligado às contas do sistema, o segundo ao indexador Spotlight. Um administrador que passe os olhos por uma lista de processos ou por um caminho de arquivo tem boa chance de considerá-los normais. Os binários são universais, com código para x86_64 e ARM64, o que cobre tanto Macs Intel quanto Apple Silicon.

A infecção também não é silenciosa: antes de prosseguir, o sistema pediu a senha do usuário, e o processo do Terminal solicitou permissões para controlar o Finder, para ler as pastas Documentos e Área de Trabalho e para controlar o aplicativo Notas. Como a conta usada no laboratório era administrativa e as permissões foram concedidas, a cadeia seguiu até o fim. Essa é a principal linha de defesa do usuário final — e também a que mais falha, porque pedidos de permissão em sequência durante uma instalação parecem legítimos.

O que o malware procurou levar

Os dados coletados foram reunidos em um arquivo out.zip no diretório /tmp. A estrutura interna, reproduzida pela Unit 42, mostra o alvo real:

• deskwallets/Binance/ e deskwallets/TonKeeper/ — carteiras de criptomoedas de desktop
• FileGrabber/aws/, FileGrabber/gcloud/, FileGrabber/docker/, FileGrabber/filezilla/ — diretórios de configuração de clientes de nuvem e transferência de arquivos
• FileGrabber/zsh_history — histórico de comandos do shell
• Telegram Data/, info e username

A máquina de teste era uma instalação limpa, sem nenhum desses aplicativos instalados. Ou seja, os diretórios vazios revelam a lista de busca do malware, não o que ele efetivamente encontrou. É uma distinção importante: em um Mac de trabalho real, ~/.aws/credentials e ~/.config/gcloud/ costumam conter tokens de longa duração que dão acesso direto a ambientes corporativos. O histórico do Zsh, por sua vez, frequentemente guarda comandos com segredos digitados à mão.

Tráfego de saída e infraestrutura descartável

O tráfego pós-infecção consistiu basicamente em requisições HTTP POST para um servidor de comando e controle em 161.35.146[.]120. As URLs iniciais carregam um parâmetro de estágio que funciona como um índice do que está sendo enviado: boot, init_session, messengers, credentials, browsers, wallets, resolve_auth e local_data.

Comparando com outra infecção observada em 31 de julho de 2026, a Unit 42 encontrou o mesmo padrão de URLs, mas um servidor diferente — 188.166.78[.]138. Esse é o ponto central do relatório e a razão pela qual os pesquisadores chamam o material de instantâneo: domínios, URLs, endereços IP, nomes de arquivo, hashes e caminhos de diretório mudam com frequência no AMOS. Os autores afirmam explicitamente que os indicadores publicados já não são os mais atuais.

Isso tem uma consequência prática direta para quem defende: tratar essa lista como regra de bloqueio é perda de tempo; tratá-la como material de caça retroativa faz sentido. O que permanece estável são os padrões — o formato das URLs por estágio, os nomes de diretório disfarçados de componentes da Apple, a sequência de permissões solicitadas pelo Terminal.

O que fazer

• Bloquear a superfície de entrada. A cadeia inteira depende de um usuário colar um comando no Terminal. Políticas de conscientização específicas para macOS e, quando possível, restrição de contas administrativas em máquinas corporativas cortam o problema na origem.
• Caçar nos diretórios citados. Procure por ~/Library/Application Support/.com.apple.accountsd/ e ~/Library/Application Support/.com.apple.metadata.mds/ — são diretórios ocultos que não existem em uma instalação padrão. Os hashes SHA-256 divulgados pela Unit 42 servem para varredura retroativa em telemetria de EDR.
• Rotacionar o que pode ter vazado. Se houver suspeita de infecção em uma máquina de desenvolvedor, a resposta não termina no Mac: chaves da AWS, credenciais do Google Cloud, tokens do Docker e senhas do FileZilla precisam ser revogados e reemitidos, e os acessos correspondentes auditados.
• Monitorar o egresso. Requisições POST repetidas para um único IP externo, com parâmetros de estágio sequenciais, são um padrão detectável independentemente de qual IP esteja em uso no momento.

O que observar a seguir

O relatório da Unit 42 não faz atribuição a um grupo específico nem estima o volume de vítimas, e não há indicação pública de campanhas direcionadas ao Brasil neste material. O que ele documenta bem é uma família em desenvolvimento ativo, com ciclo de rotação de infraestrutura medido em semanas.

Para o leitor brasileiro, o alerta útil é o deslocamento do alvo. Enquanto a cobertura sobre ladrões de macOS costuma girar em torno de carteiras de criptomoedas, o inventário coletado nesta infecção aponta para credenciais de infraestrutura em nuvem. Um único Mac de desenvolvedor comprometido pode ser o começo de um incidente em ambiente de produção — e esse caminho é bem mais silencioso do que uma carteira esvaziada.

Fontes e referências

• Unit 42 (Palo Alto Networks), Bradley Duncan — Atomic macOS (AMOS) Stealer Activity, 16 de setembro de 2026: unit42.paloaltonetworks.com
• Splunk Threat Research Team — Analytics Story: AMOS Stealer: research.splunk.com
• Darktrace — Atomic Stealer: Darktrace’s Investigation of a Growing macOS Threat: darktrace.com
• Picus Security — Atomic Stealer: Dissecting 2024’s Most Notorious macOS Infostealer: picussecurity.com
• Plugged Ninja — ClickFix no macOS: fingerprinting e cloaking para entregar o AMOS, 6 de agosto de 2026: plugged.ninja