Configurações públicas de documentos do AWS Systems Manager revelaram chaves, nomes de usuários, recursos de ECR e S3, processos de backup e mais de cinco milhões de registros de PII e transações de cartão em ambientes corporativos.
| Componente | Documentos do AWS Systems Manager compartilhados publicamente, escritos em JSON ou YAML para automatizar operações sobre recursos de nuvem. |
| Vetor | Exposição ocorre quando proprietários configuram documentos SSM como públicos e incluem credenciais, nomes de usuários, identificadores de recursos, endpoints ou rotinas operacionais sem parametrização adequada. |
| Impacto | Documentos mal configurados podem revelar informações internas de infraestrutura, apoiar engenharia social, indicar processos de implantação e backup e, em casos observados, levar à descoberta de registros de PII e transações de cartão. |
| Prioridade | Auditar documentos SSM públicos, remover segredos e metadados sensíveis, usar Parameter Store para valores variáveis e habilitar bloqueio de acesso público para SSM Documents no nível da conta. |
| Artefatos | Foram observados exemplos com activation keys, customer keys, nomes de usuários IAM em formato de e-mail, endpoints ECR, referências a buckets S3 e descrições operacionais de contas e backups. |
| Escala | A pesquisa identificou mais de 3.000 documentos SSM públicos potencialmente relacionados ao padrão de exposição e encontrou mais de cinco milhões de registros de PII e transações de cartão em ambientes de várias empresas. |
| Mitigação | Substituir valores hardcoded por parâmetros, revisar recursos AWS citados nos documentos, validar permissões de ECR e S3 e retirar de documentos públicos qualquer dado que ajude reconhecimento ou abuso de configuração. |
Documentos do AWS Systems Manager são usados para definir operações automatizadas sobre recursos de nuvem. Esses documentos podem ser criados em JSON ou YAML e descrevem ações que o serviço deve executar em ativos AWS, incluindo tarefas de administração, implantação, manutenção e backup. O comportamento padrão é privado, mas os proprietários podem compartilhá-los com outras contas AWS ou torná-los públicos. Essa capacidade é útil para padronização operacional, porém cria uma superfície de exposição quando o documento carrega valores sensíveis, nomes internos, endpoints ou detalhes suficientes para reconstruir partes do ambiente.
A análise de documentos SSM públicos mostrou que erros de entendimento do serviço e uso inadequado de parâmetros podem transformar um artefato operacional em fonte de inteligência para atacantes. O problema não depende apenas de uma credencial explícita dentro do arquivo. Mesmo quando não há senha visível, o documento pode revelar como uma conta organiza implantação, autenticação, imagens de contêiner, rotinas de backup, buckets S3 e usuários IAM. Essa combinação reduz o custo de reconhecimento e pode direcionar engenharia social, tentativas de acesso contra recursos expostos ou busca por permissões mal configuradas.
O caso é relevante porque a pesquisa encontrou documentos com chaves de ativação e chaves de cliente embutidas, além de nomes de usuários e referências a recursos internos. Também foram identificados mais de 3.000 documentos públicos potencialmente associados a esse padrão de risco. Em alguns casos, o encadeamento entre informação operacional publicada, recursos AWS referenciados e dados acessíveis levou à descoberta de mais de cinco milhões de registros de PII e transações de cartão pertencentes a várias empresas. A conclusão técnica é que documentos públicos devem ser tratados como superfície de publicação controlada, não como simples arquivos auxiliares de automação.
O fluxo de exposição começa quando um documento SSM, originalmente adequado para uso interno ou compartilhamento restrito, é configurado como público. O arquivo pode conter parâmetros de execução, nomes de recursos, descrições de tarefas e valores usados por automações. Quando valores como nomes de usuário, e-mails, chaves de ativação, chaves de cliente ou endpoints aparecem em texto claro, qualquer pessoa que consiga consultar o documento passa a ter um mapa parcial do ambiente. O atacante não precisa executar o documento para obter valor inicial: a simples leitura pode revelar estrutura, nomenclatura, contas envolvidas e dependências de serviços.
Um dos padrões observados envolve credenciais ou identificadores sensíveis inseridos diretamente no conteúdo do documento. Informações desse tipo não deveriam ser hardcoded em documentos SSM nem em código-fonte. Quando o documento precisa consumir um valor sensível ou variável, a abordagem defensiva esperada é referenciá-lo por meio do Systems Manager Parameter Store, com controle de permissões apropriado, em vez de publicar o valor literal. O risco aumenta quando apenas parte do segredo é abstraída. Um exemplo citado envolvia senha parametrizada, mas nome de usuário e endpoint de ECR permaneciam visíveis, o que ainda oferecia material suficiente para focalizar tentativas de acesso contra o registro de contêiner.
Outro padrão envolve metadados que parecem inofensivos isoladamente. Um nome de usuário IAM em formato de e-mail, por exemplo, pode não conceder acesso por si só, mas permite pesquisa aberta sobre cargo, organização, localização ou área de atuação da pessoa associada. Isso cria insumo para phishing direcionado e engenharia social com linguagem mais convincente. Da mesma forma, nomes de recursos como instâncias EC2, endpoints ECR, buckets S3 e descrições operacionais podem indicar quais ativos são críticos. Um nome que sugere acesso a banco de dados ou uma descrição relacionada a conta pagadora pode orientar o atacante para alvos de maior valor.
A exposição mais grave descrita envolve documentos que revelavam processos de backup. Um documento indicava uma rotina periódica que baixava um arquivo de um bucket S3 e o executava localmente. A análise subsequente identificou um artefato Java com grande volume de arquivos e um script de backup. A partir das referências ao bucket, foram encontrados conteúdos de backup de banco de dados, com arquivos superiores a 1 GB e dezenas de milhares de registros de PII em cada conjunto. Esse tipo de encadeamento mostra que o documento público não precisa conter o banco de dados em si para causar dano: basta expor a sequência operacional e os recursos que levam até ele.
A superfície afetada inclui contas AWS que permitem documentos SSM públicos e mantêm nesses documentos informações criadas para consumo interno. O risco é maior em ambientes onde automações antigas foram reaproveitadas, onde equipes publicam documentos para integração entre contas sem revisão de conteúdo ou onde descrições operacionais permanecem mais detalhadas do que o necessário. Como documentos SSM frequentemente descrevem tarefas de administração, eles podem expor relações entre serviços, padrões de implantação, rotinas de backup, nomes de usuários, nomes de recursos e dependências de armazenamento.
Ambientes com ECR, S3, IAM e EC2 aparecem no centro do risco descrito. Um endpoint ECR visível pode indicar onde imagens de contêiner estão armazenadas. Um bucket S3 citado em rotina de backup pode apontar para arquivos sensíveis se a política do bucket estiver permissiva ou se existirem erros adicionais de controle de acesso. Um usuário IAM em e-mail pode apoiar reconhecimento humano. Uma descrição de documento pode sugerir relação com conta pagadora, backup, banco de dados ou implantação. Nenhum desses elementos precisa ser explorável sozinho para ser útil; o valor surge quando os fragmentos se combinam.
A exposição também afeta governança e privacidade. A descoberta de registros de PII e transações de cartão mostra que a falha operacional pode sair do campo de metadados e alcançar dados regulados. O impacto técnico confirmado no contexto é exposição indevida de informações e possível facilitação de ataques subsequentes, não execução remota genérica ou comprometimento automático de todas as contas. A severidade deve ser avaliada pela presença de segredos hardcoded, acesso público a recursos referenciados, criticidade dos buckets e registros, permissões associadas ao IAM e sensibilidade dos processos documentados.
- Documentos SSM públicos contendo activation keys, customer keys, nomes de usuário ou e-mails em texto claro.
- Referências a endpoints ECR e nomes de recursos que ajudam a identificar registros de contêiner e ativos de maior valor.
- Descrições de documentos e nomes de recursos que indicam processos financeiros, acesso a banco de dados, implantação ou backup.
- Rotinas que mencionam buckets S3, arquivos de backup ou artefatos executados localmente por automações.
- Ambientes onde documentos públicos foram criados sem seguir práticas de parametrização e revisão de conteúdo.
A investigação defensiva deve começar pelo inventário de documentos SSM compartilhados publicamente e por uma revisão de conteúdo orientada a dados sensíveis. O objetivo não é apenas localizar senhas óbvias, mas detectar qualquer informação que reduza o esforço de reconhecimento. Termos relacionados a chaves, usuários, e-mails, endpoints, buckets, backups, contas pagadoras, imagens de contêiner e caminhos de implantação merecem triagem. Quando um documento público referencia recursos AWS, a equipe deve validar se esses recursos também estão expostos, se possuem políticas permissivas ou se contêm dados regulados.
Em contas AWS, a telemetria útil inclui eventos de criação, atualização e alteração de compartilhamento de documentos SSM, além de consultas e mudanças em Parameter Store, S3, ECR e IAM. A defesa deve correlacionar documentos públicos com recursos citados neles. Um bucket mencionado em documento público precisa ser verificado quanto a política, ACL, criptografia, versionamento, logs de acesso e objetos sensíveis. Um endpoint ECR citado deve ter autenticação, permissões e políticas revisadas. Usuários IAM citados por nome ou e-mail devem ser avaliados quanto a exposição pública, autenticação forte e permissões excessivas.
Hunting também deve considerar sinais de exploração indireta. A leitura pública de um documento pode não gerar o mesmo tipo de alerta que um ataque ativo contra endpoint, mas mudanças posteriores em buckets, tentativas de autenticação contra usuários citados, aumento incomum de consultas a registros de contêiner ou acesso a objetos de backup podem indicar abuso das informações publicadas. Para dados sensíveis encontrados em backups, a resposta deve incluir identificação dos tipos de dados, escopo temporal dos arquivos, contas e aplicações envolvidas, sem expor valores reais durante a documentação do incidente.
- Listagem de documentos SSM com compartilhamento público e revisão de campos contendo chaves, usuários, e-mails, endpoints, nomes de buckets e descrições operacionais.
- Correlação entre cada recurso AWS citado no documento e suas políticas efetivas de acesso, especialmente S3, ECR, IAM e EC2.
- Eventos de alteração de documento SSM, mudança de permissão de compartilhamento e uso inesperado de documentos publicados.
- Tentativas de autenticação contra usuários IAM revelados em documentos, principalmente quando o identificador tem formato de e-mail corporativo.
- Acesso incomum a buckets de backup, objetos grandes, arquivos de banco de dados e registros de contêiner referenciados por automações.
A resposta deve priorizar redução imediata da exposição pública. Documentos SSM que não precisam ser públicos devem voltar para escopo privado ou compartilhamento restrito com contas específicas. Para documentos que realmente precisam ser publicados, a equipe deve remover segredos, nomes de usuário, e-mails, endpoints desnecessários, nomes de recursos excessivamente descritivos e qualquer texto que revele função crítica do ativo. O documento público deve conter somente o mínimo operacional necessário, sem detalhes de ambiente que possam orientar reconhecimento externo.
Valores sensíveis e variáveis devem ser tratados por Parameter Store, com permissões específicas e revisão de acesso. A simples substituição de senha por parâmetro não é suficiente quando nome de usuário, endpoint e nomes de recursos continuam expostos sem necessidade. A parametrização deve cobrir todos os elementos que ajudem a identificar ambiente, conta, registro, bucket ou identidade. Quando um documento já esteve público com credenciais ou chaves, a ação correta é considerar esses valores expostos, revogá-los, rotacioná-los e revisar logs para verificar uso indevido.
Também é necessário validar os recursos referenciados pelos documentos. Buckets S3 citados em processos de backup devem ser revisados quanto a acesso público, permissões entre contas e presença de dados sensíveis. Registros ECR devem ter políticas de autenticação e autorização verificadas. Usuários IAM encontrados em documentos devem ter MFA, permissões mínimas e monitoramento de autenticação. Descrições e nomes de recursos devem ser saneados para não indicar função sensível como banco de dados, pagamento, backup ou acesso administrativo. Por fim, o bloqueio de acesso público para SSM Documents deve ser habilitado no nível da conta quando a organização não depende de documentos públicos.
Depois da correção, a validação precisa confirmar que documentos remediados não permanecem acessíveis publicamente e que caches, cópias internas, pipelines e repositórios não reproduzem os mesmos valores. Se a revisão encontrar PII, transações de cartão ou backups de banco expostos, o processo deve seguir fluxo de resposta a incidente: preservar evidências, delimitar período de exposição, identificar sistemas de origem, rotacionar credenciais associadas, revisar políticas de armazenamento e documentar impacto por tipo de dado, sem registrar valores sensíveis em relatórios operacionais.
- Remover compartilhamento público de documentos SSM que não tenham necessidade operacional comprovada.
- Substituir chaves, usuários, e-mails, endpoints e valores variáveis por referências controladas no Parameter Store, quando aplicável.
- Rotacionar qualquer credencial ou chave que tenha aparecido em documento público.
- Revisar permissões e políticas de S3, ECR, IAM e EC2 citados nos documentos expostos.
- Habilitar bloqueio de acesso público para SSM Documents no nível da conta quando o uso público não for requisito.
- Rever nomes e descrições de recursos para reduzir vazamento de contexto operacional sensível.
- Tratar backups e bases com PII encontrados a partir de documentos públicos como incidente de exposição de dados.
0 Comentários