# T1548.005 - Temporary Elevated Cloud Access
## Descrição
Adversários podem abusar de configurações de permissões em ambientes de nuvem que permitem obter acesso temporariamente elevado a recursos e serviços. Plataformas de nuvem modernas como AWS, Azure, GCP e Microsoft 365 oferecem mecanismos sofisticados de controle de acesso just-in-time (JIT), impersonação de contas e delegação de papéis, projetados para reduzir a exposição permanente a privilégios elevados. Quando mal configurados ou explorados por adversários com acesso inicial, esses mecanismos se tornam vetores de escalonamento de privilégios extremamente eficazes e difíceis de detectar.
O acesso JIT é um modelo em que contas recebem permissões adicionais somente quando necessário e por um período limitado de tempo. Em plataformas como o AWS IAM Identity Center e o Azure PIM (Privileged Identity Management), usuários podem solicitar roles temporárias que lhes dão acesso administrativo por horas ou dias. Quando essas solicitações são aprovadas automaticamente - sem revisão humana - ou quando um adversário compromete uma conta com poder de aprovar tais solicitações, o caminho para escalonamento de privilégios se abre sem deixar rastros evidentes de comportamento anômalo, pois o mecanismo JIT é legítimo por natureza.
A impersonação de contas de serviço e a delegação de papéis ampliam ainda mais essa superfície de ataque. No Google Cloud Platform (GCP), a role `iam.serviceAccountTokenCreator` permite que um usuário gere tokens de acesso temporários em nome de uma conta de serviço - potencialmente com permissões muito mais amplas. Na Microsoft 365, a role `ApplicationImpersonation` habilita contas de serviço a agirem com as permissões de usuários específicos, podendo ser explorada para exfiltrar e-mails ou acessar dados sensíveis. Já no AWS, a permissão `PassRole` permite que um usuário crie recursos - como instâncias EC2, funções Lambda ou jobs EMR - e atribua a esses recursos uma IAM role com privilégios elevados, obtendo acesso indireto às permissões da role sem jámais assumi-la diretamente.
> **Técnica pai:** [[t1548-abuse-elevation-control-mechanism|T1548 - Abuse Elevation Control Mechanism]]
> **Táticas MITRE:** Privilege Escalation, Defense Evasion
> **Técnica relacionada:** [[t1098-003-additional-cloud-roles|T1098.003 - Additional Cloud Roles]]
## Como Funciona
### Mecanismos de Acesso Temporário Exploráveis
**1. Just-in-Time Access (JIT)**
Em AWS IAM Identity Center e Azure PIM, usuários podem ser elegíveis a determinadas roles sem tê-las ativamente atribuídas. Um adversário que compromete uma conta elegível pode ativar a role por conta própria, se a aprovação for automática, ou comprometer uma conta aprovadora para aprovar a solicitação. O resultado é um token de sessão temporário com os privilégios da role ativada, válido por horas - tempo suficiente para realizar reconhecimento interno, exfiltrar dados ou criar backdoors.
**2. Impersonação de Contas de Serviço (GCP)**
No GCP, a role `iam.serviceAccountTokenCreator` é frequentemente atribuída de forma excessivamente ampla. Um adversário que obtém acesso a uma conta com essa role pode executar:
```bash
gcloud auth print-access-token --impersonate-service-account=sa-privilegiada@projeto.iam.gserviceaccount.com
```
Esse token pode ser usado para chamar APIs do GCP com as permissões da conta de serviço impersonada, potencialmente incluindo acesso a buckets do Cloud Storage, chaves do Secret Manager ou pipelines de CI/CD.
**3. Delegação de Domínio no Google Workspace**
Contas de serviço com "domain-wide delegation" podem impersonar qualquer usuário no Google Workspace, incluindo administradores. Um adversário que obtém acesso a essa conta de serviço - por exemplo, via chave JSON exposta em repositório de código - pode acessar o Gmail, Google Drive e Calendar de qualquer funcionário da organização.
**4. PassRole no AWS**
Um usuário com `iam:PassRole` e permissão para criar recursos pode atribuir uma role privilegiada a um recurso sob seu controle:
```python
# Criar função Lambda com role administrativa
lambda_client.creaté_function(
FunctionName='backdoor',
Role='arn:aws:iam::123456789:role/AdminRole',
...
)
# Invocar a função para executar ações com privilégios de AdminRole
```
Esse padrão é amplamente explorado e documentado como "privilege escalation via Lambda/EC2/CloudFormation".
**5. ApplicationImpersonation no Exchange Online**
A role `ApplicationImpersonation` do Microsoft Exchange permite que um aplicativo ou conta de serviço acesse caixas de entrada de usuários. Adversários que comprometem um service principal com essa role podem exfiltrar todos os e-mails de todos os usuários do tenant.
### Cadeia de Exploração Típica
O ataque geralmente combina acesso inicial a uma conta de baixo privilégio com enumeração de configurações de IAM para identificar caminhos de escalonamento disponíveis. Ferramentas como `Pacu` (AWS), `ScoutSuite` e `ROADtools` (Azure/M365) são comumente usadas para mapear configurações permissivas.
## Attack Flow
```mermaid
graph TB
A["Acesso Inicial<br/>(conta comprometida ou credenciais vazadas)"] --> B["Enumeração de IAM<br/>(ScoutSuite / Pacu / ROADtools)"]
B --> C{"Caminho de<br/>escalonamento?"}
C -->|JIT disponível| D["Ativar Role Temporária<br/>(Azure PIM / AWS IAM Identity Center)"]
C -->|ServiceAccountTokenCreator| E["Gerar Token de<br/>Impersonação (GCP)"]
C -->|PassRole disponível| F["Criar Recurso com<br/>Role Privilegiada (AWS Lambda/EC2)"]
C -->|ApplicationImpersonation| G["Impersonar Usuários<br/>(Exchange Online / M365)"]
D --> H["Executar Ações com<br/>Privilégios Elevados"]
E --> H
F --> H
G --> H
H --> I["Exfiltração / Movimentação Lateral<br/>/ Criação de Backdoor Persistente"]
I --> J["Cobertura de Rastros<br/>(revogar acesso temporário antes da expiração)"]
```
## Exemplos de Uso
### UNC2452 / APT29 - Comprometimento da SolarWinds (2020)
O grupo [[apt29-cozy-bear|APT29]], responsável pelo ataque à cadeia de suprimentos da [[solarwinds-supply-chain-attack|SolarWinds]], utilizou extensivamente técnicas de impersonação de tokens SAML no Azure AD para obter acesso persistente a ambientes de nuvem de múltiplas organizações governamentais e corporativas. Após comprometer o servidor de federação on-premises (ADFS), o grupo forjou tokens SAML válidos que permitiam impersonar qualquer usuário do tenant Azure, essencialmente abusando de um mecanismo de identidade temporária. Esse padrão é diretamente relacionado ao T1548.005, pois envolve o uso abusivo de mecanismos de acesso temporário baseados em tokens.
### Operadores de Ransomware Cloud-Focused (2023-2025)
Grupos de ransomware como [[g1015-scattered-spider|Scattered Spider]] (também conhecido como UNC3944) demonstraram sofisticação particular em ambientes de nuvem, abusando de funcionalidades JIT no Azure PIM e de roles permissivas no AWS para escalar privilégios após phishing de funcionários de help desk. O grupo obteve tokens de sessão temporários com permissões de Administrador Global no Azure AD, permitindo criar contas backdoor persistentes e desabilitar MFA de contas-alvo. Organizações brasileiras no setor financeiro e de telecomúnicações foram identificadas como alvos de TTPs similares.
### Ataques a Ambientes GCP com ServiceAccountTokenCreator
Pesquisadores documentaram campanhas onde adversários comprometeram instâncias de VM no GCP que possuíam a role `iam.serviceAccountTokenCreator` associada a uma conta de serviço privilegiada. A partir dessas instâncias, o adversário gerou tokens temporários e acessou dados sensíveis no Cloud Storage e Secret Manager sem necessidade de comprometer diretamente a conta de serviço alvo.
## Detecção
### Regra Sigma - Ativação Suspeita de Role JIT no Azure
```yaml
title: Suspicious Azure PIM Role Activation
status: experimental
description: Detecta ativação de role privilegiada via Azure PIM fora do horário comercial ou por conta sem histórico de ativações
logsource:
category: cloud
product: azure
service: auditlogs
detection:
selection_operation:
operationName: "Activaté eligible assignment"
selection_privileged_roles:
targetResources.modifiedProperties.newValue|contains:
- "Global Administrator"
- "Privileged Role Administrator"
- "Security Administrator"
- "Exchange Administrator"
condition: selection_operation and selection_privileged_roles
falsepositives:
- Administradores legítimos ativando roles para tarefas planejadas
- Processos de emergência documentados
level: high
tags:
- attack.privilege_escalation
- attack.t1548.005
```
### Regra Sigma - Impersonação de Conta de Serviço no GCP
```yaml
title: GCP Service Account Token Creation for Impersonation
status: experimental
description: Detecta geração de tokens de acesso para impersonação de contas de serviço no GCP
logsource:
category: cloud
product: gcp
service: audit_log
detection:
selection:
protoPayload.methodName:
- "iam.serviceAccounts.getAccessToken"
- "iam.serviceAccounts.signBlob"
- "iam.serviceAccounts.signJwt"
filter_legitimate:
protoPayload.authenticationInfo.principalEmail|endswith: ".gserviceaccount.com"
condition: selection and not filter_legitimate
falsepositives:
- Pipelines de CI/CD legítimos usando impersonação de contas de serviço
level: high
tags:
- attack.privilege_escalation
- attack.t1548.005
```
### Regra Sigma - PassRole Abusivo no AWS
```yaml
title: AWS PassRole to Privileged Resource
status: experimental
description: Detecta uso de iam:PassRole para atribuir roles administrativas a recursos recém-criados
logsource:
category: cloud
product: aws
service: cloudtrail
detection:
selection_passrole:
eventName: "PassRole"
selection_creaté_resource:
eventName:
- "CreateFunction20150331"
- "RunInstances"
- "CreateStack"
- "StartJobRun"
timeframe: 5m
condition: selection_passrole and selection_creaté_resource
falsepositives:
- Deployments legítimos via IaC (Terraform, CloudFormation)
level: medium
tags:
- attack.privilege_escalation
- attack.t1548.005
```
### Fontes de Logs Recomendadas
| Plataforma | Fonte de Log | Eventos Relevantes |
|-----------|-------------|-------------------|
| Azure | Azure AD Audit Logs | Ativações PIM, geração de tokens SAML |
| AWS | CloudTrail | AssumeRole, PassRole, GetFederationToken |
| GCP | Cloud Audit Logs | getAccessToken, signBlob, setIamPolicy |
| M365 | Unified Audit Log | New-ManagementRoleAssignment, ApplicationImpersonation |
## Mitigação
| ID | Mitigação | Descrição |
|----|-----------|-----------|
| [[m1018-user-account-management\|M1018]] | User Account Management | Revisar e auditar regularmente todas as configurações de roles elegíveis (JIT) e permissões de impersonação. Remover atribuições desnecessárias de `iam.serviceAccountTokenCreator`, `PassRole` e `ApplicationImpersonation`. Exigir aprovação humana para todas as ativações JIT de roles privilegiadas. |
| [[m1026-privileged-account-management\|M1026]] | Privileged Account Management | Implementar o princípio do menor privilégio em todas as contas cloud. Usar grupos de acesso separados para operações privilegiadas. Rotacionar regularmente as credenciais de contas de serviço e auditar seu uso. |
| [[m1032-multi-factor-authentication\|M1032]] | Multi-Factor Authentication | Habilitar MFA para todas as ativações de roles JIT e para contas com permissões de impersonação. Integrar MFA com políticas de acesso condicional no Azure AD e Google Cloud Identity. |
## Contexto Brasil/LATAM
A adoção acelerada de ambientes multi-cloud por organizações brasileiras - especialmente no setor financeiro, saúde e governo - criou uma superfície de ataque significativa para essa técnica. O Brasil é um dos países com maior crescimento de adoção de AWS, Azure e GCP na América Latina, e muitas organizações ainda estão amadurecendo suas práticas de segurança em nuvem.
Incidentes documentados no LATAM envolvendo comprometimento de ambientes cloud frequentemente exploram permissões JIT configuradas de forma excessivamente permissiva ou contas de serviço com privilégios além do necessário. A falta de visibilidade em logs de auditoria cloud - especialmente no Azure AD e GCP - dificulta a detecção oportuna.
No contexto regulatório brasileiro, a LGPD (Lei Geral de Proteção de Dados) e as resoluções do Banco Central (BACEN) para o setor financeiro exigem controles de acesso privilegiado documentados e auditáveis. O abuso de acesso temporário elevado pode violar esses requisitos mesmo que o acesso sejá técnicamente permitido pela plataforma, caso não hajá aprovação explícita e log detalhado da justificativa.
Grupos de ameaça com presença documentada no Brasil, como operadores afiliados ao ecossistema de ransomware russo e grupos de crime financeiro latino-americanos, têm demonstrado crescente sofisticação em ambientes de nuvem. O [[g1015-scattered-spider|Scattered Spider]] e grupos similares são exemplos de atores que combinam engenharia social com exploração de mecanismos JIT para comprometer organizações de grande porte.
## Referências
- [[t1548-abuse-elevation-control-mechanism|T1548 - Abuse Elevation Control Mechanism]] - técnica pai
- [[t1098-003-additional-cloud-roles|T1098.003 - Additional Cloud Roles]] - atribuição permanente de roles (distinto de acesso temporário)
- [[t1078-004-cloud-accounts|T1078.004 - Cloud Accounts]] - uso de contas cloud válidas
- [[t1550-001-application-access-token|T1550.001 - Application Access Token]] - uso de tokens de aplicação
- [[apt29-cozy-bear|APT29]] - grupo que abusou de tokens SAML no ataque SolarWinds
- [[g1015-scattered-spider|Scattered Spider]] - grupo com TTPs documentados em ambientes Azure/AWS
- [[solarwinds-supply-chain-attack|SolarWinds Supply Chain Attack]] - campanha que utilizou impersonação de tokens cloud
- [[m1018-user-account-management|M1018 - User Account Management]] - mitigação primária recomendada pelo MITRE
---
*Fonte: [MITRE ATT&CK - T1548.005](https://attack.mitre.org/techniques/T1548/005)*