Preâmbulo

Bem-vindo a mais uma edição da engenharia de detecção da AWS com a Elastic. Você pode ler a edição anterior no STS AssumeRoot aqui.

Neste artigo, vamos explorar como os agentes de ameaças aproveitam a criptografia do lado do servidor do Amazon S3 com chaves fornecidas pelo cliente (SSE-C) para operações de resgate/extorsão. Esta tática de abuso contemporânea demonstra as formas criativas com as quais os adversários podem explorar os serviços nativos de nuvem para alcançar seus objetivos financeiros.

Como leitor, você vai obter insights sobre o funcionamento interno do S3, fluxos de trabalho SSE-C e configurações de buckets. Também vamos percorrer as etapas dessa técnica, discutir as práticas recomendadas para proteger os buckets do S3 e fornecer orientações práticas para criar uma lógica de detecção que identifique o abuso de SSE-C no seu ambiente.

Esta pesquisa se baseia em uma publicação recente da Equipe de Pesquisa Halcyon, que documentou o primeiro caso conhecido publicamente de abuso de SSE-C em ambiente real para comportamento de ransomware. Junte-se a nós enquanto nos aprofundamos nessa ameaça emergente e mostramos como ficar à frente dos adversários.

Publicamos um gist contendo o código do Terraform e o script de emulação referenciados neste blog. Este conteúdo é fornecido apenas para fins educacionais e de pesquisa. Use-o com responsabilidade e de acordo com as leis e diretrizes aplicáveis. A Elastic não assume nenhuma responsabilidade por quaisquer consequências não intencionais ou uso indevido.

Aproveite!

Compreendendo o AWS S3: principais conceitos e recursos de Security

Antes de mergulharmos diretamente na emulação e nessas táticas, técnicas e procedimentos (TTPs), vamos revisar brevemente o que o AWS S3 inclui.

O S3 é o serviço de armazenamento comum da AWS que permite que os usuários armazenem qualquer dado não estruturado ou dados estruturados em "buckets". Esses buckets são semelhantes às pastas que você encontraria localmente no seu sistema de computador. Os dados armazenados nesses buckets são chamados de objetos, e cada objeto é identificado de forma única por uma chave de objeto, que funciona como um nome de arquivo. O S3 é compatível com muitos formatos de dados, desde JSON até arquivos de mídia e muito mais, tornando-o ideal para diversos casos de uso organizacionais.

Buckets podem ser configurados para armazenar objetos de vários serviços do AWS S3, mas também podem ser preenchidos manualmente ou programaticamente, dependendo do caso de uso. Além disso, os buckets podem usar o versionamento para manter várias versões de objetos, o que oferece resiliência contra exclusões ou substituições acidentais. No entanto, a versionamento nem sempre é ativado por padrão, deixando os dados vulneráveis a certos tipos de ataques, como os que envolvem ransomware ou exclusões em massa. Buckets podem ser configurados para armazenar objetos de vários serviços do AWS S3, mas também podem ser preenchidos manualmente ou programaticamente, dependendo do caso de uso. Além disso, os buckets podem usar o versionamento para manter várias versões de objetos, o que oferece resiliência contra exclusões ou substituições acidentais. No entanto, o versionamento nem sempre é ativado por padrão, deixando os dados vulneráveis a certos tipos de ataques, como aqueles que envolvem ransomware ou exclusões em massa.

O acesso a esses buckets depende bastante das suas políticas de acesso, geralmente definidas na criação. Essas políticas incluem configurações como desativar o acesso público para evitar a exposição não intencional do conteúdo dos buckets. A configuração não para por aí; os buckets também têm seu próprio Nome de Recurso da Amazon (ARN) exclusivo, o que permite que políticas de acesso mais granulares sejam definidas por meio de funções ou políticas de gerenciamento de acesso de identidade (IAM). Por exemplo, se o usuário "Alice" precisar de acesso a um bucket e seus objetos, permissões específicas, como s3:GetObject, devem ser atribuídas ao papel do IAM. Esse papel pode ser aplicado diretamente a Alice como uma política de permissão ou a um grupo associado ao qual ela pertence.

Embora esses mecanismos pareçam infalíveis, configurações incorretas nos controles de acesso (por exemplo, políticas de buckets excessivamente permissivas ou listas de controle de acesso) são uma causa comum de incidentes de segurança. Por exemplo, até o momento em que este artigo foi escrito, aproximadamente 325,8 mil buckets estavam disponíveis publicamente de acordo com buckets.grayhatwarfare.com. O Elastic Security Labs também observou que 30% das falhas nas verificações de postura da AWS estavam relacionadas ao S3 no Relatório Global de Ameaças da Elastic de 2024.

Criptografia do lado do servidor no S3
O S3 oferece múltiplas opções de criptografia para proteger dados em repouso. Alguns exemplos:

• SSE-S3: as chaves de criptografia são totalmente gerenciadas pela AWS.
• SSE-KMS: as chaves são gerenciadas pelo AWS Key Management Service (KMS), permitindo políticas de chave mais personalizadas e controle de acesso — veja como elas são implementadas na Elastic.
• SSE-C: os clientes fornecem suas próprias chaves de criptografia para ter mais controle. Esta opção é frequentemente utilizada para atender a requisitos de conformidade ou segurança específicos, mas acarreta uma sobrecarga operacional adicional, como gestão e armazenamento seguro de chaves. Importante: a AWS não armazena chaves SSE-C; em vez disso, o HMAC (código de autenticação de mensagens baseado em hash) de uma chave é logado para fins de verificação.

No caso do SSE-C, o mau gerenciamento das chaves de criptografia ou o abuso intencional (por exemplo, ransomware) pode tornar os dados permanentemente inacessíveis.

Políticas de Ciclo de Vida

Os buckets do S3 também podem utilizar políticas de ciclo de vida, que automatizam ações como a transição de objetos para classes de armazenamento mais baratas (por exemplo, Glacier) ou a exclusão de objetos após um tempo especificado. Embora essas políticas sejam normalmente usadas para otimização de custos, elas podem ser exploradas por invasores para agendar a exclusão de dados críticos, aumentando a pressão durante um incidente de ransomware.

Classes de Armazenamento

O Amazon S3 oferece várias classes de armazenamento, cada uma projetada para diferentes padrões de acesso e necessidades de frequência. Embora as classes de armazenamento geralmente sejam escolhidas para otimização de custos, é crucial entendê-las ao considerar como a criptografia e a segurança interagem com o armazenamento de dados.

Por exemplo, o S3 Padrão e o Intelligent-Tiering garantem acesso frequente com latência mínima, tornando-os adequados para aplicações em tempo real. Por outro lado, classes de arquivamento como Glacier Flexible Retrieval e Deep Archive introduzem atrasos antes que os dados possam ser acessados, o que pode complicar a resposta a incidentes em cenários de segurança.

Isso se torna especialmente relevante quando a criptografia é introduzida. A criptografia do lado do servidor (SSE) funciona em todas as classes de armazenamento, mas a SSE-C (Customer-Provided Keys) transfere a responsabilidade do gerenciamento de chaves para o usuário ou adversário. Ao contrário da criptografia gerenciada pela AWS (SSE-S3, SSE-KMS), a SSE-C exige que cada operação de recuperação forneça a chave de criptografia original — e,se essa chave for perdida ou não fornecida por um adversário, os dados se tornarão permanentemente irrecuperáveis.

Com esse entendimento, surge uma questão crítica sobre as implicações do abuso de SSE-C observado em campo: o que acontece quando um invasor obtém acesso a buckets S3 expostos publicamente ou mal configurados e têm controle sobre a política de armazenamento e as chaves de criptografia?

Assim começa: abuso de SSE-C para operações de extorsão

Na seção a seguir, vamos compartilhar uma abordagem prática para emular esse comportamento em nosso ambiente sandbox da AWS, completando o seguinte:

1. Implante infraestrutura vulnerável usando o provedor de infraestrutura como código (IaC) Terraform
2. Explore como criar solicitações SSE-C em Python
3. Execute um script personalizado para simular o comportamento de ransomware descrito no blog Halcyon

Pré-requisitos

Este artigo trata da recriação de um cenário específico para a engenharia de detecção. Se este for o seu objetivo, o seguinte deve ser estabelecido primeiro.

• O Terraform deve ser instalado localmente
• O Python 3.9+ também precisa ser instalado localmente para ser usado no ambiente virtual e para rodar um script de emulação.
• O perfil do AWS CLI deve ser configurado com privilégios administrativos para ser usado pelo Terraform durante a implantação da infraestrutura.

Implantando infraestrutura vulnerável

Para nossa emulação de whitebox, é importante replicar uma configuração do S3 que uma organização possa ter em um cenário do mundo real. Abaixo está um resumo da infraestrutura implantada:

• Região: us-east-1 (região de implantação padrão)
• S3 Bucket: um bucket de dados de folha de pagamento com nome exclusivo que contém dados sensíveis e permite criptografia controlada por adversários
• Controles de Propriedade do Bucket: impõe "BucketOwnerEnforced" para prevenir permissões baseadas em ACL
• Restrições de acesso público: o acesso público está completamente bloqueado para evitar exposição acidental
• Usuário IAM: um usuário IAM controlado por um adversário comprometido com permissões excessivas no S3; nenhum perfil de login é atribuído, pois as credenciais de chave de acesso são usadas programaticamente em outro lugar para tarefas automatizadas.
• Política do IAM: nos níveis de bucket e objeto, os adversários têm autorização para:
  • s3:GetObject
  • s3:PutObject
  • s3:DeleteObject
  • s3:PutLifecycleConfiguration
  • s3:ListObjects
  • s3:ListBucket
• Aplicado nos níveis de buckets e objeto
• Chaves de acesso IAM: as chaves de acesso são geradas para o usuário adversário, permitindo acesso programático
• Dados fictícios: dados confidenciais simulados (customer_data.csv) são carregados para o bucket

Compreender a infraestrutura é crucial para avaliar como esse tipo de ataque se desenrola. O blog Halcyon descreve a metodologia de ataque, mas fornece poucos detalhes sobre a configuração específica da AWS das organizações afetadas. Esses detalhes são essenciais para determinar a viabilidade de tal ataque e as etapas necessárias para uma execução bem-sucedida.

Acessibilidade e exposição de buckets

Para que um ataque dessa natureza ocorra, um adversário precisa obter acesso a um buckets S3 por um dos dois métodos principais:

Buckets acessíveis publicamente: se um bucket estiver configurado incorretamente com uma política de acesso público, um adversário pode interagir diretamente com ele, desde que a política de permissão do bucket permita ações como s3:PutObject, s3:DeleteObject ou s3:PutLifecycleConfiguration. Essas permissões são frequentemente atribuídas por engano usando um curinga (*) como principal, o que significa que qualquer pessoa pode executar essas operações.

Credenciais comprometidas: se um invasor obtiver credenciais da AWS (por meio de vazamentos de credenciais, phishing ou malware), ele poderá se autenticar como um usuário legítimo do IAM e interagir com o S3 como se fosse o proprietário da conta.

Na nossa emulação, presumimos que o bucket não é público, o que significa que o ataque depende de credenciais comprometidas. Isso requer que o adversário tenha obtido chaves de acesso válidas da AWS e tenha realizado a descoberta da infraestrutura em nuvem para identificar buckets S3 acessíveis. Isso geralmente é feito usando chamadas de API da AWS, como s3:ListAllMyBuckets, s3:ListBuckets ou s3:ListObjects, que revelam buckets e seus conteúdos em regiões específicas.

Permissões de IAM necessárias para execução de ataques: Para criptografar arquivos usando SSE-C e aplicar uma política de exclusão com sucesso, o adversário precisa ter as permissões de IAM adequadas. Na nossa emulação, configuramos permissões explícitas para o usuário IAM comprometido, mas em um cenário real, vários modelos de permissão poderiam permitir esse ataque:

• Políticas personalizadas excessivamente permissivas: as organizações podem, sem perceber, conceder permissões amplas do S3 sem restrições rigorosas.
• Políticas gerenciadas pela AWS: o adversário pode ter obtido credenciais associadas a um usuário ou função que possua AmazonS3FullAccess ou AdministratorAccess.
• Permissões parciais no nível do objeto: se o usuário do IAM tiver AllObjectActions, isso permite apenas ações no nível do objeto, mas não concede modificações na política de ciclo de vida ou listagem de buckets, que são necessárias para recuperar objetos e iterá-los para criptografar e sobrescrever.

O blog Halcyon não especifica quais permissões foram abusadas, mas nossa emulação de caixa branca garante que as permissões mínimas necessárias estejam em vigor para que o ataque funcione conforme descrito.

O papel do usuário do IAM comprometido
Outro fator crítico é o tipo de usuário de IAM cujas credenciais foram comprometidas. Na AWS, um adversário não precisa necessariamente de credenciais para um usuário que possua um perfil de login interativo. Muitos usuários do IAM são criados exclusivamente para acesso programático e não precisam de uma senha do AWS Management Console ou de Autenticação Multifator (MFA), ambos os quais poderiam servir como bloqueadores de segurança adicionais.

Isso significa que, se as credenciais roubadas de um usuário do IAM forem usadas para automação ou integração de serviços, o invasor terá mais facilidade para executar solicitações de API sem enfrentar desafios adicionais de autenticação.

Embora o blog Halcyon documente de forma eficaz a técnica utilizada neste ataque, ele não fornece detalhes sobre a configuração subjacente da AWS da vítima. Compreender a infraestrutura por trás dos ataques — como o acesso a buckets, permissões do IAM e papéis de usuário — é crucial para avaliar como essas operações de resgate se desenrolam na prática. Como esses detalhes não são fornecidos, precisamos fazer suposições informadas para entender melhor as condições que permitiram que o ataque fosse bem-sucedido.

Nossa emulação é projetada para replicar as condições mínimas necessárias para esse tipo de ataque, assegurando uma avaliação realista das estratégias defensivas e das capacidades de detecção de ameaças. Ao explorar os aspectos técnicos da infraestrutura, podemos fornecer insights mais profundos sobre possíveis mitigações e como as organizações podem se defender proativamente contra ameaças semelhantes.

Configurando a infraestrutura

Para a implantação da nossa infraestrutura, utilizamos o Terraform como nosso framework de IaC. Para manter esta publicação simplificada, armazenamos a configuração do Terraform e o script de emulação atômica em um gist que pode ser baixado para fácil acesso. A seguir está a estrutura de arquivos local esperada assim que esses arquivos forem baixados.

Depois de configurar os arquivos necessários localmente, você pode criar um ambiente virtual Python para este cenário e instalar as dependências necessárias. Depois que o ambiente estiver configurado, execute o seguinte comando para inicializar o Terraform e implantar a infraestrutura:

Comando: python3 s3\_sse\_c\_ransom.py deploy

Quando a implantação estiver concluída, a infraestrutura necessária da AWS estará pronta para prosseguir com a emulação e execução do ataque. É importante notar que o acesso público está bloqueado, e a política do IAM é aplicada apenas ao usuário do IAM gerado dinamicamente por razões de segurança. No entanto, recomendamos muito desmontar a infraestrutura assim que o teste for concluído ou após capturar os dados necessários.

Se você acessar seu console da AWS ou usar a CLI, pode verificar se o bucket na região us-east-1 existe e contém customer_data.csv,, que, ao ser baixado, estará em texto simples. Você vai notar que “ransom.note” também não existe.

Entenda como criar solicitações S3 SSE-C em Python

Antes de executar a emulação atômica, é importante conhecer a técnica subjacente que permite a um adversário realizar com sucesso esse ataque ItW.

Para quem conhece a AWS, as operações do S3 — como acessar buckets, listar objetos ou criptografar dados — geralmente são diretas ao usar os SDKs da AWS ou a CLI da AWS. Essas ferramentas abstraem grande parte da complexidade, permitindo que os usuários executem operações sem precisar de um conhecimento profundo da mecânica subjacente da API. Isso também reduz a barreira de conhecimento para um adversário tentando abusar dessas funcionalidades.

No entanto, o blog do Halcyon destaca um detalhe técnico crucial sobre a execução do ataque:

"O invasor inicia o processo de criptografia chamando o cabeçalho x-amz-server-side-encryption-customer-algorithm, utilizando uma chave de criptografia AES-256 que ele mesmo gera e armazena localmente."

A principal distinção aqui é o uso do cabeçalho x-amz-server-side-encryption-customer-algorithm, que é necessário para operações de criptografia neste ataque. De acordo com a documentação da AWS, esse cabeçalho SSE-C geralmente é especificado ao criar URLs pré-assinadas e utilizar o SSE-C no S3. Isso significa que o atacante não só criptografa os dados da vítima, mas o faz de modo que a própria AWS não armazene a chave de criptografia, tornando a recuperação impossível sem a cooperação do invasor.

URLs pré-assinados e seu papel no abuso de SSE-C

O que são URLs pré-assinadas?
URLs pré-assinados são solicitações de API assinadas que permitem que os usuários realizem operações específicas do S3 por um tempo limitado. Esses URLs são frequentemente usados para compartilhar objetos de forma segura sem expor as credenciais da AWS. Um URL pré-assinado concede acesso temporário a um objeto S3 e pode ser acessado através de um navegador ou utilizado programaticamente em requisições de API.

Em um ambiente típico da AWS, os usuários aproveitam SDKs ou wrappers de CLI para URLs pré-assinados. No entanto, ao usar o SSE-C, a AWS exige cabeçalhos adicionais para criptografar ou descriptografar.

SSE-C e cabeçalhos HTTP obrigatórios
Ao fazer solicitações SSE-C, seja por meio do AWS SDK ou de chamadas diretas à REST API do S3, os seguintes cabeçalhos devem ser incluídos:

• x-amz-server-side-encryption-customer-algorithm: especifica o algoritmo de criptografia, mas deve ser AES256 (notado no relatório da Halcyon)
• x-amz-server-side-encryption-customer-key: fornece uma chave de criptografia de 256 bits codificada em base64 para o S3 usar para criptografar ou descriptografar seus dados
• x-amz-server-side-encryption-customer-key-MD5: fornece um resumo MD5 de 128 bits codificado em base64 da chave de criptografia; o S3 usa esse cabeçalho para uma verificação de integridade da mensagem para garantir que a chave de criptografia foi transmitida sem erros ou adulteração

Ao buscar oportunidades de detecção, esses detalhes são cruciais.

AWS Signature Version 4 (SigV4) e seu papel

As requisições ao S3 são autenticadas ou anônimas. Como a criptografia SSE-C com URLs pré-assinados requer autenticação, todas as solicitações devem ser assinadas criptograficamente para comprovar sua legitimidade. É aqui que entra a AWS Signature Version 4 (SigV4).

A AWS SigV4 é um mecanismo de autenticação que garante que as solicitações de API para serviços da AWS sejam assinadas e verificadas. Isso é especialmente importante para operações SSE-C, já que modificar objetos no S3 requer chamadas de API autenticadas.

Para este ataque, cada solicitação de criptografia precisa ser assinada por:

1. Gerando uma assinatura criptográfica usando AWS SigV4
2. Incluindo a assinatura nos cabeçalhos da requisição
3. Anexando os cabeçalhos de criptografia SSE-C necessários
4. Enviando a solicitação para o S3 para sobrescrever o objeto com a versão criptografada

Sem a assinatura correta da SigV4, a AWS rejeita essas requisições. Ataques como o descrito por Halcyon dependem de credenciais comprometidas, e sabemos disso porque as requisições não foram rejeitadas em nossos testes. Isso também sugere que os adversários sabem que podem explorar configurações incorretas do AWS S3, como requisitos de assinatura inadequados, e compreender as complexidades dos buckets e seus respectivos controles de acesso a objetos. Isso reforça a suposição de que o ataque se baseou em credenciais comprometidas da AWS, em vez de um bucket S3 exposto e acessível ao público, e que os adversários eram suficientemente habilidosos para entender as nuances não apenas dos buckets e objetos do S3, mas também da autenticação e criptografia na AWS.

Ativando nossa emulação atômica

Nossa emulação atômica usará as credenciais "comprometidas" do usuário do IAM sem perfil de login que possui uma política de permissão anexada, permitindo várias ações do S3 no nosso bucket de destino. Como lembrete, a infraestrutura e o ambiente em que estamos conduzindo isso foram implementados a partir da seção "Configurando a Infraestrutura", referenciando nosso gist compartilhado.

Abaixo está um fluxo de trabalho passo a passo da emulação.

1. Carregar credenciais roubadas da AWS (recuperadas de variáveis de ambiente)
2. Estabelecer o cliente S3 com credenciais comprometidas
3. Gerar URL do endpoint S3 (Construir a URL do bucket)
4. Enumerar objetos S3 → s3:ListObjectsV2 (Recuperar lista de objetos)
5. Gerar chave de criptografia AES-256 (gerada localmente)
6. Iniciar Loop (para cada objeto nos buckets)
   1. Gere uma solicitação GET e assine com AWS SigV4 (autentique a solicitação)
   2. Recuperar objeto do S3 → s3:GetObject (buscar dados não criptografados)
   3. Gere uma solicitação PUT e assine com AWS SigV4 (anexe os cabeçalhos SSE-C)
   4. Criptografar e sobrescrever objeto no S3 → s3:PutObject (criptografar com SSE-C)
7. Fim do loop
8. Aplicar política de exclusão de 7 dias → s3:PutLifecycleConfiguration (destruição de dados com restrição de tempo)
9. Carregar a nota de resgate para o S3 → s3:PutObject (mensagem de extorsão deixada para a vítima)

Abaixo está uma representação visual deste fluxo de trabalho de emulação:

Em nosso script Python, intencionalmente adicionamos prompts que exigem a interação do usuário para confirmar que ele concorda em não abusar desse script. Outro prompt gerado durante a detonação que interrompe a execução para dar tempo ao usuário para a investigação da AWS, se necessário, antes de excluir os objetos S3. Como o SSE-C é utilizado, os objetos são então criptografados com uma chave à qual o Terraform não tem acesso e, portanto, falhará.

Comando: python s3\_sse\_c\_ransom.py detonate

Após a detonação, os objetos em nosso buckets S3 serão criptografados com SSE-C, uma nota de resgate terá sido carregada e um ciclo de vida de expiração terá sido adicionado.

Se você tentar acessar o objeto customer_data.csv, a AWS rejeitará a solicitação porque ele foi store usando criptografia do lado do servidor. Para recuperar o objeto, é preciso uma solicitação assinada que inclua a chave de criptografia AES-256 correta.

Limpeza

A limpeza para esta emulação é relativamente simples. Se você escolher manter os objetos do S3, comece com a etapa 1. Caso contrário, vá direto para a etapa 5.

1. Vá para a região us-east-1
2. Navegue até o S3
3. localize o s3-sse-c-ransomware-payroll-XX bucket
4. remova todos os objetos
5. Comando: python s3\_sse\_c\_ransom.py cleanup

Assim que concluído, tudo que foi implantado inicialmente será removido.

Estratégias de detecção e busca

Após nossa emulação atômica, é crucial compartilhar como podemos detectar efetivamente esse comportamento de ransomware com base nos logs de eventos da API fornecidos pelo CloudTrail da AWS. Observe que vamos aproveitar o Elastic Stack para a ingestão de dados e o desenvolvimento de consultas iniciais; no entanto, a lógica e o contexto da consulta devem ser traduzíveis para o seu SIEM de escolha. Também é importante observar que os eventos de dados do S3 na configuração do CloudTrail devem ser configurados para "Log all events".

Criptografia incomum de objetos do AWS S3 com SSE-C

O objetivo desta estratégia de detecção é identificar solicitações de PutObject que utilizam SSE-C, já que chaves de criptografia fornecidas pelo cliente podem ser um forte indicador de atividade anômala — sobretudo se uma organização usar principalmente a criptografia gerenciada pela AWS por meio do KMS (SSE-KMS) ou a criptografia nativa do S3 (SSE-S3).

Na nossa emulação, PutObject requisições foram configuradas com o cabeçalho x-amz-server-side-encryption-customer-algorithm definido como AES256, indicando à AWS que chaves fornecidas pelo cliente foram usadas para criptografia (SSE-C).

Felizmente, o AWS CloudTrail faz logs desses detalhes de criptografia nos parâmetros de solicitação, permitindo que as equipes de segurança detectem o uso incomum de SSE-C. Principais atributos do CloudTrail para monitorar:

• SignatureVersion: SigV4 → Indica que esta solicitação foi assinada
• SSEApplied: SSE_C → Indica que a criptografia com chave do cliente no lado do servidor foi utilizada
• bucketName: s3-sse-c-ransomware-payroll-96 → Sinaliza em qual buckets isso aconteceu
• x-amz-server-side-encryption-customer-algorithm: AES256 → Indica qual algoritmo foi utilizado para a chave de criptografia do cliente
• key: customer_data.csv → Indica o nome do objeto ao qual isso foi aplicado

Com esses detalhes, já podemos elaborar uma consulta de detecção de ameaças que corresponderá a esses eventos e, por fim, à ameaça relatada no blog original do Halcyon.

Embora essa detecção seja ampla, as organizações devem ajustá-la ao seu ambiente, perguntando:

• Esperamos URLs pré-assinados com SigV4 para operações de buckets ou objeto do S3?
• Esperamos que o SSE-C seja usado para operações PutObject no S3 ou neste bucket específico?

Reduzindo falsos positivos com novos tipos de regras de termo
Para minimizar os falsos positivos (FPs), podemos usar o tipo de regra New Terms da Elastic, que ajuda a detectar ocorrências de atividade suspeita pela primeira vez. Em vez de gerar alertas para cada correspondência, rastreamos combinações únicas de usuários do IAM e buckets do S3 afetados, gerando alertas apenas quando esse comportamento é observado pela primeira vez em um período definido. Algumas das combinações únicas que observamos:

• Usuários únicos do IAM (ARNs) realizando criptografia SSE-C no S3.
• Buckets específicos onde o SSE-C é aplicado.

Esses alertas só são acionados se essa atividade tiver sido observada pela primeira vez nos últimos 14 dias.

Essa abordagem adaptativa assegura que os casos de uso legítimos sejam assimilados ao longo do tempo, evitando alertas repetidos em operações previstas. Ao mesmo tempo, sinaliza ocorrências anômalas de SSE-C pela primeira vez no S3, auxiliando na detecção precoce de ameaças. Conforme necessário, exceções de regras podem ser adicionadas para ARNs de identidade de usuário específicos, buckets, objetos ou até mesmo IPs de origem para refinar a lógica de detecção. Ao incorporar o contexto histórico e as linhas de base comportamentais, este método melhora a fidelidade do sinal, aumentando tanto a eficácia das detecções quanto a capacidade de ação dos alertas.

Referências de Regras

Criptografia incomum de objetos do AWS S3 com SSE-C
Criptografia excessiva de objetos do AWS S3 com SSE-C

Conclusão

Agradecemos por dedicar seu tempo para ler esta publicação e, se leu, por experimentar a emulação por conta própria. O teste Whitebox desempenha um papel crucial na segurança da nuvem, permitindo a replicação de ameaças do mundo real, a análise de seus padrões comportamentais e o desenvolvimento de estratégias de detecção eficazes. Com os ataques baseados em nuvem se tornando cada vez mais comuns, é essencial compreender as ferramentas por trás das táticas dos adversários e compartilhar os resultados das pesquisas com a comunidade de segurança em geral.

Se tiver interesse em explorar nosso conjunto de regras de detecção da AWS, você pode encontrá-lo aqui: Elastic AWS Detection Rules. Também aceitamos contribuições para aprimorar nosso conjunto de regras — seus esforços ajudam a fortalecer as defesas coletivas, e nós os valorizamos muito!

Incentivamos qualquer pessoa interessada a revisar a publicação da Halcyon e agradecemos antecipadamente por compartilhar a pesquisa deles!

Até a próxima.

Referências importantes:

Blog de pesquisa Halcyon sobre SSE-C ItW
Código de Emulação Elastic para SSE-C na AWS
Conjunto de regras de detecção de ameaças pré-criadas da AWS Elastic
Repositório de regras de detecção pré-criadas da Elastic
Regra: criptografia incomum de objetos AWS S3 com SSE-C
Regra: criptografia excessiva de objetos AWS S3 com SSE-C