# T1195 - Supply Chain Compromise ## Descrição O comprometimento de cadeia de suprimentos ocorre quando adversários manipulam produtos ou mecanismos de entrega de software **antes** que o destinatário final os receba. Em vez de atacar diretamente o alvo, o agressor infiltra um elo intermediário - um fornecedor de software, uma ferramenta de desenvolvimento, um pacote de código aberto ou até hardware físico - transformando componentes confiáveis em vetores de infecção. Esse modelo é particularmente perigoso porque a vítima instala o malware de forma voluntária e legítima, acreditando tratar-se de uma atualização ou biblioteca segura. O ataque pode ocorrer em qualquer ponto da cadeia: manipulação de repositórios de código-fonte públicos ou privados, alteração de mecanismos de distribuição e atualização de software, inserção de código malicioso em dependências de código aberto amplamente utilizadas (como pacotes pip, npm ou Maven), ou até a substituição de imagens de sistema e firmware durante o processo de fabricação e envio. Adversários sofisticados também exploram a "segunda ordem" de comprometimento - usando o acesso obtido em uma vítima da cadeia de suprimentos para propagar o ataque a um conjunto ainda maior de organizações downstream. **Contexto Brasil/LATAM:** No Brasil e na América Latina, o risco de comprometimento da cadeia de suprimentos é amplificado pelo alto grau de dependência de fornecedores de software de terceiros, especialmente no setor financeiro e no governo. Grupos como [[g0049-oilrig|OilRig]] e [[g0034-sandworm|Sandworm Team]] demonstraram capacidade de comprometer integradores e revendedores regionais para alcançar alvos em países como Brasil, Argentina e México. A baixa adoção de práticas como verificação de integridade de pacotes (checksums, assinaturas GPG) e SBOMs (Software Bill of Materials) pelas empresas brasileiras aumenta a jánela de exposição. O incidente SolarWinds de 2020, embora com foco nos EUA, teve reflexos em clientes LATAM de MSSPs que usavam o Orion. ## Attack Flow ```mermaid graph TB A([Fornecedor / Repositório]) -->|código malicioso inserido| B([Pacote / Atualização]) B -->|distribuição legítima| C([Organização Alvo]) C -->|instalação confiável| D([Execução Inicial]) D:::highlight -->|persistência + C2| E([Comprometimento]) classDef highlight fill:#e74c3c,color:#fff ``` ## Como Funciona **Passo 1 - Infiltração do elo fraco** O adversário identifica um fornecedor, repositório ou ferramenta de desenvolvimento com menor maturidade de segurança que sejá amplamente utilizado pelo alvo. O comprometimento pode ocorrer via credenciais roubadas de um desenvolvedor, exploração de uma vulnerabilidade no pipeline de CI/CD, ou engenharia social contra um mantenedor de pacote open-source. A técnica [[t1195-001-compromise-software-dependencies-and-development-tools|T1195.001]] detalha específicamente o vetor de dependências e ferramentas de desenvolvimento. **Passo 2 - Inserção de código malicioso** Uma vez com acesso ao repositório ou sistema de build, o adversário insere código backdoor no software legítimo. A modificação é projetada para ser discreta - muitas vezes ocultada em arquivos de configuração, rotinas de atualização automática ou funções auxiliares raramente auditadas. O código malicioso pode implementar técnicas como [[t1059-command-and-scripting-interpreter|execução de scripts]], coleta de credenciais via [[lumma-stealer|Lumma Stealer]] ou estabelecimento de canal C2 com [[s1148-raccoon-stealer|Raccoon Stealer]]. **Passo 3 - Distribuição e execução na vítima** O software comprometido é distribuído pelos canais normais do fornecedor - atualizações automáticas, CDNs, gerenciadores de pacotes. A organização alvo instala o componente infectado acreditando ser legítimo, fornecendo ao adversário acesso inicial sem qualquer interação direta ou exploração de vulnerabilidade no ambiente da vítima. A partir desse ponto, o atacante executa as próximas fases da campanha. ## Detecção **Event IDs relevantes (Windows)** | Event ID | Canal | O que detecta | |----------|-------|---------------| | 4688 | Security | Criação de processo - binários recém-instalados com comportamento anômalo | | 7045 | System | Instalação de novo serviço após atualização de software | | 4663 | Security | Acesso a arquivos de sistema logo após instalação de pacote | | 1 | Sysmon | Criação de processo com hash não catalogado | | 11 | Sysmon | Criação de arquivo em diretórios de sistema por processo de instalação | | 3 | Sysmon | Conexão de rede iniciada por binário recém-instalado | **Sigma Rule - Detecção de Execução Suspeita Pós-Instalação** ```yaml title: Suspicious Process Execution After Software Installation id: a7c3e2f1-4b8d-4e9a-bc12-3d5f6e7a8b9c status: experimental description: > Detecta processo filho suspeito criado imediatamente após instalação de software - possível indicador de comprometimento da cadeia de suprimentos. references: - https://attack.mitre.org/techniques/T1195/ author: RunkIntel daté: 2026-03-24 logsource: category: process_creation product: windows detection: selection_parent: ParentImage|endswith: - '\msiexec.exe' - '\setup.exe' - '\install.exe' - '\updaté.exe' selection_child_suspicious: Image|endswith: - '\powershell.exe' - '\cmd.exe' - '\wscript.exe' - '\cscript.exe' - '\regsvr32.exe' - '\rundll32.exe' - '\mshta.exe' timeframe: 60s condition: selection_parent and selection_child_suspicious falsepositives: - Instaladores legítimos que executam scripts de configuração pós-instalação level: medium tags: - attack.initial_access - attack.t1195 ``` ## Mitigação | ID | Mitigação | Aplicação Prática para Organizações Brasileiras | |----|-----------|------------------------------------------------| | [[m1013-application-developer-guidance\|M1013]] | Orientação a Desenvolvedores | Exigir que equipes de desenvolvimento usem lockfiles, verifiquem hashes de dependências e adotem política de revisão de dependências novas. Promover SBOM (Software Bill of Materials) em contratos com fornecedores. | | [[m1016-vulnerability-scanning\|M1016]] | Varredura de Vulnerabilidades | Integrar scanners de composição de software (SCA) ao pipeline CI/CD para detectar pacotes comprometidos ou com CVEs conhecidos antes do deploy. Ferramentas como Dependabot e Snyk são acessíveis. | | [[m1033-limit-software-installation\|M1033]] | Limitar Instalação de Software | Restringir via GPO/MDM a instalação de software não aprovado. Manter allowlist de executáveis e verificar assinaturas digitais em todos os pacotes instalados. | | [[m1051-update-software\|M1051]] | Atualizar Software | Paradoxalmente, a atualização automática pode ser vetor de ataque - válidar assinaturas criptográficas de atualizações antes de aplicar. Testar em ambiente isolado antes de produção. | | [[m1018-user-account-management\|M1018]] | Gerenciamento de Contas | Aplicar o princípio do menor privilégio nos processos de instalação. Scripts de instalação não devem rodar com SYSTEM/root sem necessidade. Monitorar contas de serviço criadas por instaladores. | | [[m1046-boot-integrity\|M1046]] | Integridade de Boot | Para organizações críticas (infraestrutura, finanças), implementar Secure Boot e verificação de integridade de firmware para mitigar comprometimento de hardware na cadeia. | ## Threat Actors O grupo [[g0034-sandworm|Sandworm Team]], ligado ao GRU russo, é responsável pelo comprometimento da cadeia de suprimentos do software de contabilidade ucraniano M.E.Doc em 2017, que distribuiu o destrutivo NotPetya - um dos ataques de supply chain mais devastadores da história, com danos estimados em bilhões de dólares globalmente. O grupo também comprometeu ferramentas de atualização de software para acesso inicial em múltiplas campanhas de sabotagem de infraestrutura crítica. O [[g0049-oilrig|OilRig]] (APT34), grupo iraniano, utilizou compromissos de cadeia de suprimentos para infiltrar organizações no Oriente Médio e acesso a redes governamentais. Embora seu foco histórico não sejá a LATAM, campanhas recentes indicam expansão de alvos para setores de energia e telecomúnicações em países emergentes. O [[g1003-ember-bear|Ember Bear]] (UAC-0056) compromete fornecedores de software para atingir alvos governamentais e de infraestrutura crítica no leste europeu, com técnicas documentadas que incluem modificação de instaladores legítimos e abuso de pipelines CI/CD corporativos. ## Software Associado O [[lumma-stealer|Lumma Stealer]] é frequentemente entregue por meio de pacotes Python e npm maliciosos públicados em repositórios públicos, disfarçados de bibliotecas legítimas de automação e criptografia. É um dos principais payloads de comprometimento de cadeia de suprimentos observados no Brasil em 2024-2025, com distribuição via PyPI typosquatting. O [[s1148-raccoon-stealer|Raccoon Stealer]] tem sido distribuído via instaladores de software crackeado e atualizações falsas de aplicações populares, um modelo de distribuição que explora a cadeia de suprimentos "informal" de software não-licenciado - modelo especialmente prevalente em PMEs brasileiras. ## Sub-técnicas - [[t1195-001-compromise-software-dependencies|T1195.001 - Compromise Software Dependencies and Development Tools]] - [[t1195-001-compromise-software-dependencies-and-development-tools|T1195.001 - Compromise Software Dependencies and Development Tools]] - [[t1195-002-compromise-software-supply-chain|T1195.002 - Compromise Software Supply Chain]] - [[t1195-002-supply-chain-compromise|T1195.002 - Supply Chain Compromise: Compromise Software Supply Chain]] - [[t1195-003-compromise-hardware-supply-chain|T1195.003 - Compromise Hardware Supply Chain]]