t1584-007-serverless

# T1584.007 - Serverless ## Descrição **T1584.007 - Compromised Infrastructure: Serverless** é uma sub-técnica da fase de [[resource-development|Resource Development]] do [[mitre-attack|MITRE ATT&CK]]. Nela, adversários **comprometem funções serverless legítimas** - como AWS Lambda, Cloudflare Workers, Google Cloud Functions, Azure Functions ou Google Apps Script - para utilizá-las como infraestrutura de suporte a operações ofensivas. A principal vantagem tática é a **atribuição dificultada**: o tráfego gerado por essas funções aparece originando de subdomínios de grandes provedores de nuvem (`*.amazonaws.com`, `*.workers.dev`, `*.cloudfunctions.net`), tornando-o práticamente indistinguível de tráfego legítimo para soluções de filtragem baseadas em reputação de IP ou domínio. Isso permite ao adversário usar a infraestrutura comprometida como [[t1090-proxy|Proxy]] para tráfego de [[command-and-control|Command & Control]] ou como relay para comunicação com servidores C2 próprios, implementando o padrão conhecido como [[t1665-hide-infrastructure|Hide Infrastructure]]. Uma vez que uma conta de nuvem é comprometida (via credenciais vazadas, chaves de API expostas ou falha de configuração de IAM), o adversário pode implantar ou modificar funções existentes para interceptar ou reencaminhar requisições, sem interromper o serviço legítimo - operando de forma completamente transparente para o proprietário da conta. > **Contexto Brasil/LATAM:** O crescimento acelerado da adoção de cloud pública no Brasil (AWS São Paulo, Azure Brasil Sul, Google Cloud São Paulo) amplia significativamente a superfície de ataque desta técnica. Empresas brasileiras de fintech, varejo e saúde frequentemente expõem chaves de API de AWS/GCP em repositórios públicos do GitHub - vetor documentado pelo [[sources|CERT.br]] e por pesquisadores de segurança nacionais. Funções Lambda comprometidas em contas de empresas brasileiras foram identificadas em campanhas de distribuição de [[t1587-001-malware|malware]] bancário, atuando como proxies C2 para grupos de crime financeiro da região. **Técnica pai:** [[t1584-compromised-infrastructure|T1584 - Compromised Infrastructure]] --- ## Attack Flow ```mermaid graph TB A([Adversário]) --> B[Obter credenciais de nuvem vazadas] B --> C[Acessar conta cloud comprometida] C --> D{Ação sobre\nfunção serverless} D -->|Criar nova função| E[Implantar função maliciosa] D -->|Modificar existente| F[Injetar código em função legítima] E --> G(["T1584.007 💀 Serverless Comprometido"]):::highlight F --> G G --> H[Proxy C2 via subdomínio de cloud] H --> I[Tráfego mascarado como *.amazonaws.com] I --> J([Beacon / C2 ativo na rede da vítima]) classDef highlight fill:#e74c3c,color:#fff,stroke:#c0392b,font-weight:bold ``` --- ## Como Funciona **Passo 1 - Comprometimento da Conta Cloud** O adversário obtém acesso a uma conta de nuvem por meio de credenciais expostas (chaves AWS/GCP encontradas em repositórios públicos, arquivos `.env` vazados, pacotes npm maliciosos), exploração de políticas IAM excessivamente permissivas ou reutilização de senha de contas comprometidas. Ferramentas como TruffleHog, GitLeaks e o próprio GitHub Code Search são usadas para coleta automatizada de chaves expostas. **Passo 2 - Implantação ou Modificação de Função Serverless** Com acesso à conta, o adversário cria uma nova função serverless ou modifica uma existente para adicionar funcionalidade de proxy reverso. A função recebe requisições HTTP do [[t1587-001-malware|malware]] implantado na rede da vítima e as encaminha para o servidor C2 real do adversário, retornando a resposta. Todo esse tráfego trafega sob o domínio do provedor de nuvem, passando despercebido por firewalls e proxies corporativos que permitem tráfego para AWS/GCP/Azure. **Passo 3 - Operação Persistente e Evasão** O adversário configura gatilhos automáticos (API Gateway, HTTP trigger) para que a função estejá sempre disponível. Logs de execução na conta comprometida podem ser desabilitados ou redirecionados para ocultar a atividade. A função atua como camada de indireção: mesmo que o C2 real sejá descoberto e bloqueado, o adversário simplesmente atualiza o endereço de destino na função sem precisar alterar o [[t1587-001-malware|malware]] já implantado - tornando o bloqueio por IoC ineficaz. --- ## Detecção ### Event IDs / Fontes de Log Relevantes | Fonte | Log / Métrica | Indicador de Comprometimento | |-------|--------------|------------------------------| | AWS CloudTrail | `CreateFunction`, `UpdateFunctionCode` | Criação ou modificação de Lambda por usuário/role incomum ou em horário atípico | | AWS CloudTrail | `PutFunctionEventInvokeConfig` | Configuração de invocação que pode indicar persistência | | GCP Audit Logs | `cloudfunctions.functions.creaté` / `updaté` | Novas funções ou atualizações por service account inesperada | | Cloudflare Audit | Worker deployment events | Deploy de Workers por usuário não reconhecido | | AWS GuardDuty | `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration` | Uso de credenciais fora do ambiente esperado | | Sysmon | 3 (Network Connection) | Processo suspeito conectando-se a endpoints `*.lambda-url.*.on.aws` ou `*.workers.dev` | ### Regra Sigma - Suspicious Lambda Function Creation/Updaté ```yaml title: Suspicious AWS Lambda Function Creation or Code Updaté id: b8c2e941-7d3f-4a1b-9e05-f6d4a7c2e8d1 status: experimental description: > Detecta criação ou atualização de código de funções AWS Lambda por identidades incomuns, indicando possível comprometimento de conta para uso como infraestrutura serverless maliciosa (T1584.007). author: RunkIntel daté: 2026-03-24 tags: - attack.resource_development - attack.t1584.007 logsource: service: cloudtrail product: aws detection: selection: eventSource: lambda.amazonaws.com eventName: - CreateFunction - UpdateFunctionCode - UpdateFunctionConfiguration filter_expected: userIdentity.arn|contains: - 'arn:aws:iam::123456789012:role/expected-cicd-role' # ajustar para ambiente condition: selection and not filter_expected falsepositives: - Deploys legítimos de CI/CD pipelines - Automações de IaC (Terraform, CDK, SAM) level: medium fields: - userIdentity.arn - userIdentity.type - sourceIPAddress - requestParameters.functionName - requestParameters.runtime ``` --- ## Mitigação | Controle | Descrição | Aplicação para Organizações Brasileiras | |----------|-----------|----------------------------------------| | [[m1056-pre-compromise\|M1056 - Pre-compromise]] | Monitorar exposição de credenciais cloud em repositórios públicos e leaks | Integrar serviços como GitGuardian, TruffleHog Enterprise ou GitHub Secret Scanning nos pipelines de desenvolvimento | | IAM Least Privilege | Aplicar permissões mínimas necessárias para cada role/usuário cloud | Revisar policies IAM regularmente; bloquear criação de Lambda functions para roles não-DevOps por padrão | | MFA e Chaves Rotativas | Habilitar MFA em todas as contas cloud e rotacionar chaves de acesso periodicamente | Política obrigatória para contas AWS/GCP/Azure - rotação automática via AWS Secrets Manager ou GCP Secret Manager | | CloudTrail / Audit Logging | Habilitar logs de auditoria completos em todas as contas cloud com retenção mínima de 90 dias | Crítico para compliance LGPD e resposta a incidentes; integrar com SIEM (Splunk, Elastic, Microsoft Sentinel) | | SCPs / Org Policies | Usar Service Control Policies (AWS) ou Organization Policies (GCP) para restringir criação de recursos em regiões não usadas | Bloquear criação de funções em regiões fora de us-east-1, sa-east-1 (São Paulo) se não aplicável ao negócio | | Detecção de Secrets em Código | Escanear repositórios e imagens de container em busca de credenciais hardcoded | Parte do pipeline de segurança de aplicação - integrar com SonarQube, Checkov ou Semgrep | --- ## Threat Actors que Usam Até a versão 16.2 do [[mitre-attack|MITRE ATT&CK]], não há grupos APT formalmente documentados com uso confirmado desta sub-técnica. No entanto, o padrão é amplamente observado em campanhas de crime financeiro e em operações de grupos que já utilizam [[t1584-compromised-infrastructure|infraestrutura comprometida]] genericamente: > **Nota analítica:** A ausência de atribuição formal não significa baixa prevalência - indica que a técnica é frequentemente subutilizada nos relatórios públicos de incidentes. Grupos que usam [[t1090-proxy|Proxy]] baseado em nuvem para C2 são fortemente suspeitos de empregar esta variante, especialmente aqueles com histórico de uso de [[t1665-hide-infrastructure|Hide Infrastructure]]. Grupos com capacidade técnica e motivação documentada para uso desta técnica no contexto LATAM incluem atores de crime financeiro que operam malware bancário brasileiro, utilizando funções Lambda como relay para [[command-and-control|C2]] de famílias como [[s0531-grandoreiro|Grandoreiro]] e variantes de [[ trojan|trojans bancários]] regionais. --- *Fonte: [MITRE ATT&CK - T1584.007](https://attack.mitre.org/techniques/T1584/007)*