# T1136.003 - Criação de Conta em Nuvem ## Técnica Pai Esta é uma sub-técnica de [[t1136-create-account|T1136 - Criação de Conta]]. ## Descrição Adversários com nível de acesso suficiente podem criar contas em plataformas de nuvem - como AWS, Azure, GCP ou provedores de identidade (IdP) - para estabelecer um mecanismo de persistência que não depende de ferramentas remotas instaladas nos sistemas da vítima. Diferente de backdoors tradicionais, contas em nuvem legítimas são frequentemente negligenciadas durante a resposta a incidentes, pois se confundem com atividades normais de administração. Além de contas de usuário comuns, adversários exploram contas de serviço - como service principals e managed identities no Azure, service accounts no GCP, e IAM roles no AWS - que podem ser vinculadas a funções serverless, máquinas virtuais e aplicações OAuth. Essa vinculação permite que o atacante execute código ou acesse recursos sem nunca precisar autenticar interativamente. Em muitos casos, a conta maliciosa é criada com permissões mínimas intencionalmente, reduzindo a probabilidade de detecção por alertas de privilégio elevado. Uma vez que a conta está criada, o adversário costuma encadear outras técnicas: adicionar credenciais adicionais via [[t1098-001-additional-cloud-credentials|T1098.001 - Additional Cloud Credentials]], atribuir funções de alto privilégio por meio de [[t1098-003-additional-cloud-roles|T1098.003 - Additional Cloud Roles]], ou utilizá-la para [[t1548-005-temporary-elevated-cloud-access|T1548.005 - Temporary Elevated Cloud Access]]. Em ambientes federados, a conta criada pode também ser usada para movimentação lateral entre tenants e organizações. **Contexto Brasil/LATAM:** O grupo [[g1004-lapsus|LAPSUS$]], com histórico de ataques a empresas brasileiras e latino-americanas, utilizou amplamente a criação de contas em nuvem após comprometer credenciais de colaboradores via engenharia social e extorsão a insiders. O Brasil, como maior mercado de nuvem pública da América Latina, concentra um volume crescente de workloads em AWS e Azure - tornando a detecção de contas espúrias em ambientes de nuvem uma prioridade para equipes de SOC na região. ## Attack Flow ```mermaid graph TB A[Acesso Inicial<br/>Credenciais Comprometidas] --> B[Escalonamento de Privilégios<br/>Acesso ao Painel de Controle da Nuvem] B --> C{{"T1136.003<br/>Criação de Conta em Nuvem"}} C --> D[T1098.001<br/>Adicionar Credenciais à Conta] C --> E[T1098.003<br/>Atribuir Roles de Alto Privilégio] D --> F[Acesso Persistente<br/>Sem Ferramentas no Host] E --> F F --> G[Movimentação Lateral<br/>Entre Serviços e Tenants] G --> H[Exfiltração / Impacto] ``` ## Como Funciona 1. **Preparação** - O adversário obtém credenciais de um administrador de nuvem (via phishing, compra em fóruns criminais ou acesso de insider) com permissão para criar usuários ou service principals. 2. **Execução** - Uma nova conta é criada no provedor de nuvem alvo. No Azure, isso pode ser feito via portal, CLI (`az ad sp creaté`) ou chamadas à Microsoft Graph API. No AWS, o atacante usa `iam:CreateUser` ou `iam:CreateRole`. No GCP, usa `gcloud iam service-accounts creaté`. 3. **Pós-execução** - A conta recém-criada recebe credenciais (senha, token ou certificado) e, opcionalmente, permissões elevadas. O adversário pode então operar como um usuário legítimo, acessando Storage, bancos de dados, funções Lambda/Functions e pipelines de CI/CD. **Exemplo - criação de service principal no Azure via CLI:** ```bash # Criar service principal com papel de Contributor az ad sp creaté-for-rbac \ --name "backup-service-prod" \ --role Contributor \ --scopes /subscriptions/<subscription-id> # Resultado: clientId, clientSecret e tenantId para uso posterior ``` ## Detecção **Fontes de dados:** logs de auditoria do provedor de nuvem (Azure AD Audit Logs, AWS CloudTrail `CreateUser`/`CreateRole`, GCP Cloud Audit Logs), alertas de CASB, eventos de Identity Provider (Okta, Entra ID). ```yaml title: Criação Suspeita de Conta em Nuvem id: a3f1b2c4-d5e6-7890-abcd-ef1234567890 status: experimental logsource: product: azure service: auditlogs detection: selection: OperationName: - "Add service principal" - "Add user" - "Add member to role" InitiatedBy.User.UserPrincipalName|endswith: - "@outlook.com" - "@gmail.com" filter_admin: InitiatedBy.User.UserPrincipalName|contains: "admin" condition: selection and not filter_admin falsepositives: - Onboarding legítimo de novos colaboradores - Automações de IaC (Terraform, Pulumi) level: high tags: - attack.persistence - attack.t1136.003 ``` ## Mitigação | Mitigação | Orientação Prática | |-----------|-------------------| | [[m1032-multi-factor-authentication\|M1032 - Multi-factor Authentication]] | Exigir MFA para criação de usuários e service principals; bloquear criação via API sem MFA step-up | | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Aplicar princípio de menor privilégio; revisar periodicamente contas e roles atribuídas a service principals | | [[m1030-network-segmentation\|M1030 - Network Segmentation]] | Restringir acesso às APIs de gerenciamento de identidade por IP de origem; usar Conditional Access no Azure e SCPs na AWS | ## Threat Actors que Usam - [[g0016-apt29|APT29]] - utilizou service principals no Azure para manter acesso persistente pós-compromisso do SolarWinds - [[g1004-lapsus|LAPSUS$]] - criou contas em ambientes de nuvem após extorquir insiders e roubar credenciais MFA ## Software Associado - [[s0677-aadinternals|AADInternals]] - toolkit para manipulação de Azure AD, inclui criação e enumeração de service principals ## Referências *Fonte: [MITRE ATT&CK - T1136.003](https://attack.mitre.org/techniques/T1136/003)*