t1590-003-network-trust-dependencies

# T1590.003 - Network Trust Dependencies ## Descrição Adversários podem coletar informações sobre as dependências de confiança de rede da organização alvo com o objetivo de identificar vetores alternativos de acesso que exploram relações de confiança estabelecidas entre redes. Essas dependências incluem conexões privilegiadas com organizações de segunda e terceira camada - provedores de serviços gerenciados (MSPs), empresas terceirizadas de TI, consultores de segurança, fornecedores de software, parceiros de negócios e subsidiárias - que possuem acesso elevado ou conectividade direta com a rede do alvo principal. A lógica por trás dessa técnica é que organizações grandes e bem protegidas frequentemente têm defesas robustas em seu perímetro direto, mas as empresas que possuem acesso legítimo à sua rede - como MSPs, fornecedores de ERP, empresas de contabilidade ou parceiros logísticos - podem ter postura de segurança significativamente mais fraca. Ao comprometer um elo mais fraco na cadeia de confiança, o adversário obtém acesso privilegiado ao alvo final por meio de canais considerados confiáveis, contornando controles de segurança tradicionais baseados em perímetro. Esta técnica está intimamente ligada à sub-técnica [[t1591-002-business-relationships|T1591.002 - Business Relationships]] e constitui o fundamento para ataques de supply chain e ataques via relacionamentos de confiança ([[t1199-trusted-relationship|T1199]]). A coleta de informações sobre dependências de confiança de rede pode ser conduzida por meio de engenharia social ([[t1598-phishing-for-information|Phishing for Information]]), análise de documentos públicos (contratos, relatórios anuais, comúnicados de imprensa), pesquisa em redes sociais e análise de registros DNS e certificados TLS que revelam relações de parceria. ## Como Funciona O mapeamento de dependências de confiança de rede ocorre em múltiplas camadas. Na fase de coleta passiva, o adversário analisa fontes abertas para identificar relacionamentos organizacionais e técnicos: **Fontes Abertas e OSINT:** - **LinkedIn e redes sociais profissionais**: identificação de funcionários de TI que mencionam tecnologias específicas, parceiros e fornecedores. Vagas de emprego frequentemente revelam a stack tecnológica e os parceiros de integração da organização. - **Registros públicos corporativos**: contratos governamentais públicados, relatórios de auditoria, declarações regulatórias (CVM no Brasil) revelam fornecedores críticos. - **Comúnicados de imprensa e casos de estudo**: fornecedores frequentemente públicam estudos de caso sobre suas implementações, revelando que empresas são clientes e quais sistemas gerenciam. - **Análise de DNS e certificados**: registros SPF/DKIM revelam provedores de e-mail terceirizados; certificados TLS com nomes alternativos (SANs) revelam domínios relacionados e parceiros de hospedagem; análise de WHOIS e registros DNS históricos via Passive DNS identificam infraestrutura compartilhada. **Análise Técnica:** - **BGP e roteamento**: análise de tabelas BGP (via RIPEstat, BGPlay, RouteViews) revela peerings privados e conexões de rede entre organizações relacionadas. - **Análise de certificados**: plataformas como crt.sh e Certificaté Transparency logs revelam certificados emitidos para subdomínios que indicam sistemas de parceiros com acesso à rede interna. - **Shodan/Censys**: identificação de sistemas VPN, jump hosts e gateways de acesso remoto que aceitam conexões de faixas de IP específicas, revelando parceiros com acesso direto. **Engenharia Social:** O adversário pode contatar diretamente funcionários se passando por parceiros, auditores ou fornecedores ([[t1598-phishing-for-information|Phishing for Information]]) para obter informações sobre a arquitetura de rede e os parceiros de integração. A informação coletada alimenta diretamente ataques de [[t1199-trusted-relationship|Trusted Relationship]], onde o adversário compromete um parceiro de menor segurança para obter acesso privilegiado ao alvo principal. ## Attack Flow ```mermaid graph TB A["Identificação do Alvo Principal Empresa de alto valor"] --> B["Mapeamento de Dependências OSINT · DNS · BGP · Certificados"] B --> C["Inventário de Parceiros MSPs · Fornecedores · Subsidiárias"] C --> D["Avaliação de Postura de Segurança Qual parceiro é mais vulnerável?"] D --> E["Comprometimento do Elo Fraco Trusted Relationship Attack"] E --> F["Acesso Privilegiado ao Alvo Via canal de confiança estabelecido"] F --> G1["Movimento Lateral Remote Services"] F --> G2["Coleta de Dados Data from Local System"] F --> G3["Implante de Backdoor Develop Capabilities"] ``` ## Exemplos de Uso ### Ataque SolarWinds - Cadeia de Confiança em Escala Global O caso mais paradigmático de exploração de dependências de confiança de rede é o ataque à SolarWinds em 2020, atribuído ao [[g0016-apt29|APT29]] (Cozy Bear). O adversário identificou que a SolarWinds era um MSP/fornecedor de software crítico para milhares de organizações governamentais e corporativas nos EUA e globalmente. Ao comprometer o processo de build da SolarWinds e inserir o backdoor SUNBURST no software Orion, o grupo obteve acesso privilegiado a redes de clientes que confiavam nas atualizações automáticas do software. Esse ataque demonstra como o mapeamento de dependências de confiança de rede pode escalar o impacto de um único comprometimento para centenas de alvos de alto valor. ### Kaseya VSA - Comprometimento de MSP Em julho de 2021, o grupo [[revil-ransomware|REvil]] explorou uma vulnerabilidade zero-day no Kaseya VSA (software de gerenciamento remoto usado por MSPs) para comprometer simultaneamente centenas de empresas gerenciadas. A seleção do Kaseya como alvo foi precedida de reconhecimento específico para identificar MSPs com ampla base de clientes, demonstrando aplicação sistemática de T1590.003 para maximizar o alcance do ataque. ### APT Groups - Ataques a Fornecedores de Defesa Grupos de ameaça com nexo estatal frequentemente mapeiam dependências de confiança no setor de defesa. Ao identificar que grandes empreiteiros de defesa dependem de fornecedores menores de componentes eletrônicos ou software especializado, adversários comprometem esses fornecedores menores para obter projetos técnicos e propriedade intelectual do contratante principal. Essa técnica foi documentada em operações atribuídas ao [[g0045-apt10|APT10]] contra fornecedores de serviços gerenciados no Jápão, EUA e Europa. ### Comprometimento de Provedores de E-mail Adversários que identificam que uma organização-alvo terceiriza seu serviço de e-mail para um provedor específico podem tentar comprometer esse provedor para interceptar comúnicações, realizar ataques de [[t1566-phishing|phishing]] altamente convincentes com domínios legítimos, ou obter credenciais de acesso via reset de senha. ## Detecção A detecção proativa de reconhecimento de dependências de confiança é altamente desafiadora, pois ocorre externamente. O foco deve estar na detecção de acesso anômalo via canais de confiança legítimos. ```yaml title: Acesso Anômalo via Parceiro ou Fornecedor Terceirizado status: experimental description: | Detecta padrões de acesso incomuns originados de faixas de IP de parceiros/MSPs, especialmente fora de horário comercial ou com comportamento atípico para a conta. logsource: category: authentication product: windows detection: selection_external_access: EventID: - 4624 - 4625 LogonType: 3 AuthenticationPackageName: 'NTLM' filter_business_hours: # Acessos de parceiros fora do horário comercial (ajustar conforme timezone) TimeCreated|gte: '20:00:00' TimeCreated|lte: '06:00:00' selection_privileged_account: TargetUserName|contains: - 'admin' - 'svc' - 'service' - 'mssp' - 'vendor' condition: selection_external_access and filter_business_hours and selection_privileged_account level: medium tags: - attack.reconnaissance - attack.t1590.003 - attack.initial_access - attack.t1199 falsepositives: - Manutenção de emergência fora do horário comercial - Parceiros em fusos horários diferentes ``` ### Detecção Complementar - Monitoramento de Canais de Confiança | Vetor | Controle de Detecção | |-------|---------------------| | Acesso VPN de parceiros | Alertas para horários incomuns e volumes de tráfego atípicos | | Jump hosts / Bastion hosts | Logging detalhado de todas as sessões; alertas para comandos suspeitos | | Ferramentas RMM (AnyDesk, TeamViewer) | Inventário e monitoramento de sessões não autorizadas | | Certificados de parceiros | Monitoramento de Certificaté Transparency para novos certificados suspeitos | ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1056-pre-compromise\|M1056]] | Pre-compromise | Limitar informações sobre parceiros e arquitetura de rede disponíveis públicamente. Rever o que é revelado em comúnicados de imprensa e vagas de emprego. | ### Controles Adicionais Recomendados | Controle | Descrição | |----------|-----------| | Zero Trust Architecture | Não confiar implicitamente em conexões de parceiros; exigir autenticação forte para cada sessão | | Segmentação de Rede para Terceiros | Parceiros devem ter acesso apenas aos sistemas estritamente necessários, em segmento isolado | | Revisão de Contratos de MSP | Incluir cláusulas de segurança, direito de auditoria e notificação obrigatória em caso de incidente | | Inventário de Acessos Privilegiados | Manter registro atualizado de todos os terceiros com acesso à rede e revisar periodicamente | | Monitoramento de Threat Intelligence | Assinar feeds de inteligência que cubram comprometimentos de fornecedores e MSPs | ## Contexto Brasil/LATAM O Brasil possui um ecossistema de TI com alta dependência de fornecedores e MSPs, especialmente no segmento de médias empresas e no setor público. A terceirização de infraestrutura de TI é extremamente comum, com muitas organizações delegando gestão de redes, segurança e servidores a empresas de menor porte que frequentemente possuem postura de segurança inadequada. Esse padrão cria cadeias de confiança com elos significativamente fracos. No setor financeiro brasileiro, regulamentações do Banco Central (BCB) exigem gestão de risco de terceiros, mas a implementação prática ainda é inconsistente. Grupos de ameaça que visam instituições financeiras brasileiras frequentemente mapeiam fornecedores de software bancário, empresas de processamento de pagamentos e prestadores de serviços de TI como vetores alternativos de entrada. O setor de saúde brasileiro também é vulnerável: hospitais e clínicas frequentemente dependem de fornecedores de sistemas de prontuário eletrônico (SISS, MV, Tasy) que possuem acesso privilegiado às redes internas. Um comprometimento desses fornecedores pode fornecer acesso a dados sensíveis de pacientes e sistemas críticos de centenas de unidades de saúde simultaneamente. A Lei Geral de Proteção de Dados (LGPD) introduziu obrigações de gestão de risco de terceiros no Brasil, mas a conformidade ainda está em desenvolvimento. Operadores devem garantir que seus operadores subcontratados (terceiros com acesso a dados pessoais) possuam controles de segurança adequados - o que inclui monitorar dependências de rede confiáveis. ## Referências **Técnicas Relacionadas:** - [[t1590-gather-victim-network-information|T1590 - Gather Victim Network Information]] (técnica pai) - [[t1591-002-business-relationships|T1591.002 - Business Relationships]] (técnica complementar) - [[t1199-trusted-relationship|T1199 - Trusted Relationship]] (exploração do que foi mapeado) - [[t1598-phishing-for-information|T1598 - Phishing for Information]] (coleta ativa de informações) - [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]] - [[t1595-active-scanning|T1595 - Active Scanning]] - [[t1583-acquire-infrastructure|T1583 - Acquire Infrastructure]] - [[t1584-compromise-infrastructure|T1584 - Compromise Infrastructure]] **Threat Actors e Campanhas Relacionadas:** - [[g0016-apt29|APT29]] (SolarWinds/SUNBURST) - [[g0045-apt10|APT10]] (Operações contra MSPs) - [[revil-ransomware|REvil]] (Kaseya VSA) **Mitigações:** - [[m1056-pre-compromise|M1056 - Pre-compromise]] --- *Fonte: [MITRE ATT&CK - T1590.003](https://attack.mitre.org/techniques/T1590/003)*