O que precisa de saber sobre ransomware na AWS

Por pior que seja o problema do ransomware nos data centers, eu estava um pouco cético de que ele fosse algo relevante na nuvem. Pessoalmente, eu nunca havia me deparado com nenhum incidente, e comecei a achar que era mais teórico do que qualquer outra coisa. Acontece que eu estava um pouco errado. Ok, totalmente errado. O problema não só é maior do que eu imaginava, como o padrão de ataque também era diferente do que eu esperava dentro da Amazon Web Services (AWS).

Na conferência AWS re:Inforce, participei de uma excelente sessão conduzida por Kyle Dickinson, Megan O’Neil e Karthik Ram. Estava completamente lotada, e o responsável pela sala teve de dispensar dezenas de pessoas. Este post é uma espécie de resumo da sessão, combinado com minhas próprias experiências e recomendações a respeito de ransomware na AWS. Quaisquer erros e omissões são meus, não deles.

Principais destaques:

• Agentes de ransomware estão cada vez mais visando ambientes da Amazon Web Services (AWS), muitas vezes explorando lacunas no acesso de identidades, nas configurações de armazenamento e na visibilidade entre serviços.
• Os buckets do Amazon S3 são um ponto de entrada comum, com atacantes criptografando ou excluindo dados críticos em razão de políticas fracas ou da falta de imposição de criptografia.
• Uma defesa eficaz contra ransomware na nuvem exige uma estratégia em camadas, incluindo controle de acesso, monitoramento em tempo real e fluxos de trabalho de resposta rápida.
• A FireMon fortalece a postura de segurança de dados ao monitorar continuamente configurações incorretas, aplicar políticas em escala e fornecer visibilidade que ajuda as equipes a responder mais rapidamente a ameaças de ransomware na nuvem.

O ransomware na Amazon AWS é um problema

Sim. Acontece que o ransomware na AWS é um problema maior do que eu imaginava inicialmente. Clientes reais estão sendo afetados, não se trata de algo meramente teórico.

Como funciona um ataque de ransomware na Amazon

Vou tratar do vetor inicial de exploração na próxima questão, mas existem quatro possíveis técnicas de ataque de ransomware na Amazon:

• Os atacantes comprometem uma instância (muitas vezes por phishing de um usuário/administrador, nem sempre por comprometimento direto) e então instalam seu malware para criptografar os dados e se propagar para outras instâncias alcançáveis. Isso não é realmente diferente do ransomware em um data center, já que não envolve nada específico da nuvem.
• O atacante copia dados de um bucket do S3 e depois exclui os dados originais. Esse é o ransomware nativo de nuvem na Amazon mais comumente observado.
• Um agente mal-intencionado criptografa os dados do S3 usando uma chave KMS sob seu controle. Isso é mais teórico do que real, devido a múltiplos fatores. É muito mais fácil simplesmente excluir um objeto/bucket do que criptografá-lo retroativamente.
• Um atacante faz algo com os dados em outro serviço de armazenamento para bloquear/excluir os dados. Estou sendo vago porque isso não é observado, e a maioria desses serviços tem limitações internas e resiliência integrada que tornam o ransomware difícil de executar.

O ransomware visa mais comumente os buckets do AWS S3, com os atacantes copiando e depois excluindo os dados. Instâncias/servidores também podem ser alvo do mesmo malware usado para atacar data centers. Existem alguns ataques teóricos que não são realmente vistos na prática.

Um novo ataque de ransomware na Amazon, no entanto, vem ganhando força: as gangues de ransomware começaram a criptografar dados no local usando a criptografia do lado do servidor da AWS com chaves fornecidas pelo cliente (SSE-C). Essa técnica permite que os atacantes criptografem arquivos diretamente nos seus buckets do S3 sem removê-los ou disparar alertas padrão, e a recuperação é impossível sem a chave de criptografia personalizada do atacante.

Como os agentes de ameaça obtêm acesso para realizar ataques de ransomware na Amazon Web Services

Credenciais expostas. Quase sempre chaves de acesso estáticas, mas possivelmente chaves obtidas de uma instância comprometida (por meio do serviço de metadados). Ou seja, praticamente como funcionam quase todos os ataques de segurança baseada em nuvem.

Qual é a sequência de um ataque de ransomware ao S3

Vou me concentrar no cenário de ransomware em bucket do S3, já que esse é o caso nativo de nuvem no qual queremos focar.

• O atacante obtém credenciais.
• O atacante usa as credenciais para reconhecimento, a fim de determinar quais chamadas de API são permitidas e identificar os recursos que pode acessar.
• O atacante descobre que tem permissões de escrita no S3 e acesso de listagem/leitura para identificar buckets. Observe que o atacante pode não ter privilégios de List, mas pode obter os nomes dos buckets de outras fontes, como DNS, GitHub ou outros locais. Isso é muito menos provável.
• O atacante copia/move os dados para outro local, que não está necessariamente na AWS.
• O atacante exclui os objetos/arquivos de origem.
• O atacante carrega uma nota de resgate (ou envia por e-mail).

Em campanhas recentes, os atacantes também começaram a usar políticas do S3 Object Lifecycle Management para marcar arquivos criptografados para exclusão em até sete dias, aumentando a urgência de pagar o resgate. Eles costumam deixar um arquivo warning.txt no diretório afetado com um endereço de carteira Bitcoin e um ID exclusivo da vítima.

Como tudo isso é automatizado, o processo pode começar em menos de um minuto após a exposição de uma credencial.

Como detectar ransomware no Amazon S3

Bem, se não for possível pular direto para a prevenção de ransomware no S3…

O atacante normalmente deixa uma nota com informações de contato para que você possa enviar Bitcoin, o que é conveniente. Mas é provável que a maioria de vocês queira identificar o problema antes disso. Vamos percorrer a sequência do ataque de ransomware ao Amazon S3 para ver onde é possível detectá-lo.

Primeiro, será preciso habilitar um monitoramento mais aprofundado dos seus buckets sensíveis. Como este post já está ficando mais longo do que eu gostaria, vou deixar de lado todos os detalhes de como identificar e gerenciar esses buckets e, em vez disso, focar em algumas fontes-chave a considerar. Por questões de custo, não espere ativá-las para tudo:

• CloudTrail, claro.
• CloudTrail Data Events para quaisquer buckets que sejam importantes para você. Isso tem custo adicional.
• GuardDuty.
• Opcional: Security Hub. Essa é a melhor maneira de agregar o GuardDuty e outros serviços de segurança da AWS em todas as suas contas.
• Talvez: S3 Server Access Logs. Se você tiver CloudTrail Data Events, obterá a maior parte do que precisa. Mas os logs do S3 são gratuitos para criar (você paga apenas pelo armazenamento) e capturam alguns eventos que o CloudTrail pode deixar passar (por exemplo, autenticações malsucedidas). Eles também levam horas para aparecer, portanto não são úteis durante um incidente em andamento. Leia mais neste guia do usuário.

Agora que tratamos do monitoramento, vejamos as sete etapas do processo de detecção:

1. Detecção de credenciais expostas e atividade de reconhecimento

O processo de detecção começa com a identificação, própria ou por terceiros, de chaves da AWS divulgadas publicamente ou comprometidas, bem como de qualquer atividade suspeita. Normalmente por meio da varredura de um repositório comum, como o GitHub. A Amazon Web Services uma vez encontrou uma das minhas e me enviou um e-mail. Ops.

As suas detecções de reconhecimento de credenciais de conta funcionam aqui. Algumas opções incluem:

• Descobertas do GuardDuty, como exfiltração de credenciais. No entanto, há um atraso de cerca de 20 minutos, e existem técnicas de evasão
• A chamada de API GetCallerIdentity nem sempre é maliciosa, mas não é uma chamada que você deveria ver com frequência em contas de produção
• GetAccountAuthorizationDetails deve disparar um alarme todas as vezes
• Múltiplas chamadas de API malsucedidas a partir de uma única entidade IAM

2. Atenção à enumeração do S3

Agora começamos a focar nas detecções de ransomware na AWS que indicam que o atacante está se concentrando no S3. Você provavelmente percebe que a detecção precoce nessas fases pode ser difícil por causa do ruído, mas tenha em mente que elas serão mais viáveis em situações como contas de produção gerenciadas via CI/CD com acesso humano limitado. Isso pode até motivá-lo a usar mais padrões nativos de nuvem.

As descobertas do GuardDuty para S3 referentes a eventos de Discovery, que precisam ser habilitadas além de simplesmente ativar o GuardDuty, dependendo de como sua conta e sua organização estão configuradas. Filtre por eventos de Read e List Management e Data Events malsucedidos no serviço S3. Você pode flagrar o atacante fazendo reconhecimento. Isso pode ser feito no seu SIEM, mas também é fácil criar CloudWatch Metrics Filters para esses casos.

3. Monitoramento de leituras e cópias de objetos

Aqui, você está monitorizar continuamente para verificar se o atacante está a ler os objetos e a fazer cópias. Se ler (copiar) e depois eliminar cada objeto, esta ação pode confundir-se com a fase seguinte.

4. Detetar a eliminação em massa e a colocação da nota de resgate

Esta é a fase do “oh não”. O atacante já não está apenas a observar, está a executar o ataque e a eliminar os dados copiados. As deteções de exfiltração/impacto em S3 do GuardDuty entram em ação. Recorde-se de que são necessários pelo menos 20 minutos para o acionamento e, consoante o número de objetos, este pode ser um indicador tardio. O CloudTrail Insights, caso o utilize, alerta para o elevado número de eventos Write usados para mover os dados.

Pode criar as suas próprias deteções para um elevado número de chamadas de eliminação. Consoante o seu ambiente e os padrões de atividade normais, este número pode ser baixo e ser acionado mais depressa do que o GuardDuty. O seu SIEM e os CloudWatch Metrics Filters são boas opções.

5. Identificar o abuso de SSE-C (encriptação silenciosa)

Monitorize a aplicação súbita de cabeçalhos SSE-C em chamadas de API como PutObject — um sinal de que os dados podem estar a ser encriptados com a chave do atacante. Uma vez que a AWS regista apenas um hash HMAC das operações, a recuperação forense convencional é impossível sem monitorização proativa.

6. Utilizar canary buckets e deteção de KMS

As organizações maduras podem semear as contas com canary buckets/objetos e emitir alertas sobre quaisquer operações que toquem nesses buckets. Embora seja um padrão de ataque menos comum, pode alertar as pessoas para a utilização de uma chave KMS a partir do exterior da sua conta.

7. Escalamento e resposta a incidentes

Se está a detetar o ataque nesta fase, já foi comprometido. É altura de responder. Contacte as autoridades e acione a equipa de resposta a incidentes de clientes da AWS.

Proteção contra ransomware na AWS: como posso manter a minha empresa segura

Para executar com êxito um ataque de ransomware na AWS, o agente malicioso precisa de três condições:

• Acesso a credenciais
• Permissões para ler e escrever no S3
• A capacidade de eliminar objetos que não podem ser recuperados

A primeira camada na prevenção de ransomware consiste em restringir o IAM e, em seguida, utilizar as ferramentas nativas da AWS para garantir resiliência. É fácil de dizer e difícil de fazer, mas eis uma lista de verificação centrada no S3, na qual tentarei omitir a maior parte dos controlos e práticas de higiene mais comuns:

• Não permita de todo utilizadores IAM com chaves de acesso estáticas. Se tal não for possível, utilize sem falta as suas ferramentas para identificar quaisquer utilizadores com permissões de eliminação no S3.
• Exija MFA aos utilizadores SSO/federados. Sempre e para sempre.
• Faça com que os administradores escalem para uma função IAM diferente quando precisarem de realizar operações de eliminação. Pode inclusivamente separar por completo as permissões de leitura e de eliminação em funções distintas.
• Se uma instância necessitar de acesso ao S3, certifique-se de que limita as permissões o mais estritamente possível às chamadas de API mínimas necessárias sobre os recursos mínimos.
• Desative o SSE-C, salvo se for absolutamente necessário. Isto ajuda a prevenir ataques de encriptação silenciosa que podem bloquear o acesso aos seus dados sem qualquer via de recuperação.
• Utilize um endpoint de VPC para aceder ao bucket e acrescente uma política de recursos que permita a eliminação apenas a partir da VPC de origem. Assim, o atacante não pode utilizar as credenciais fora dessa VPC.
• Ative o versionamento, o AWS Backup e/ou a replicação de buckets. Todas estas medidas asseguram que não perde o acesso aos seus dados. Bem, a menos que estrague MESMO as suas políticas de IAM e dê carta branca ao atacante. Algumas destas opções têm de ser ativadas no momento da criação do bucket, pelo que poderá ser necessária uma operação de migração para as implementar.

Vai reparar que estou a omitir o Block Public Access. É uma excelente funcionalidade, mas muitas organizações têm dificuldade em implementá-la em escala, uma vez que precisam de alguns buckets públicos e esta não ajuda em ataques que utilizam credenciais expostas.

Tudo isto exige esforço e acrescenta custos, pelo que recomendo vivamente que comece por se concentrar nos buckets que realmente importam. Existem estratégias mais avançadas, sobretudo se gerir ambientes de maior dimensão, que não cabem num artigo, mas contacte-me se quiser falar sobre elas.

O que aprendeu de novo sobre ransomware no S3 na sessão Re:Inforce

Não sabia que o ransomware no S3 era tão comum. Também não sabia que copiar e depois eliminar era a técnica de ataque preferida. Julgava que se recorria à encriptação com KMS e faz todo o sentido que essa seja mais teórica e rara. Já conhecia os detetores e as defesas, mas os oradores da AWS fizeram um trabalho notável ao articulá-los de forma muito clara e aplicável. A apresentação superou seguramente as minhas expectativas.

Como pode a FireMon ajudar a minha empresa na proteção contra ransomware no S3

Temos um novo produto IAM em Beta para privilégios Just in Time que deverá ser lançado em breve. Oferecemos também verificações de postura e detetores de ameaças no DisruptOps para identificar buckets de risco e emitir alertas sobre atividades maliciosas, tais como ataques de ransomware. Contacte-me se quiser falar sobre eles, ou mesmo se pretender apenas aconselhamento geral sobre as opções da AWS que mencionei no artigo.

Marque hoje uma demonstração e veja como a FireMon o pode ajudar a proteger a sua empresa contra ransomware na AWS.