# T1593.003 - Code Repositories > [!info] Identificação MITRE ATT&CK > **Tática:** Reconnaissance · **ID:** T1593.003 · **Técnica pai:** [[t1583-001-domains|Domains]] ## Descrição A técnica **T1593.003 - Code Repositories** descreve como adversários realizam pesquisas em repositórios públicos de código-fonte para coletar informações sobre organizações-alvo que possam ser utilizadas em operações de ataque. Plataformas como GitHub, GitLab, Bitbucket e SourceForge hospedam bilhões de linhas de código e são usadas por organizações de todos os tamanhos para colaboração em desenvolvimento de software. Embora o propósito principal sejá o compartilhamento de código, esses repositórios frequentemente contêm informações altamente sensíveis expostas inadvertidamente: credenciais hardcoded, chaves de API, tokens de autenticação, strings de conexão com bancos de dados, configurações de infraestrutura e documentação interna. A exposição acidental de segredos em repositórios públicos é um problema endêmico na indústria de software. Desenvolvedores frequentemente fazem commit de arquivos `.env`, `config.yaml`, `appsettings.json` ou `secrets.properties` durante testes locais e, por descuido ou falta de treinamento, públicam esses arquivos em repositórios públicos. Ferramentas de varredura automatizada como `truffleHog`, `gitleaks`, `detect-secrets` e `git-secrets` são usadas tanto por equipes de segurança legítimas quanto por adversários para identificar esses vazamentos em escala. O GitHub Search API permite que qualquer pessoa pesquise por padrões específicos em todo o conteúdo público indexado, tornando a varredura automatizada trivialmente simples. Além de credenciais e segredos, repositórios públicos revelam informações estratégicas valiosas: arquitetura de sistemas internos (através de README, diagramas de infraestrutura como código e Dockerfiles), linguagens e frameworks utilizados ([[t1592-002-software|T1592.002]]), nomes e e-mails de desenvolvedores (úteis para engenharia social), e histórico completo de commits que pode revelar configurações removidas mas ainda recuperáveis via `git log`. Grupos como [[g1004-lapsus|LAPSUS$]] tornaram a busca sistemática em repositórios de código uma marca registrada de suas operações, obtendo acesso a sistemas críticos de grandes empresas através de credenciais encontradas no GitHub. > [!note] Distinção importante > Esta técnica (T1593.003) é distinta de [[t1213-003-code-repositories|T1213.003 - Code Repositories]], que trata da coleta de dados em repositórios **privados e internos** após o compromisso inicial. T1593.003 é uma técnica de **reconhecimento pré-compromisso** que opera exclusivamente em repositórios **públicos**. ## Como Funciona **Varredura automatizada com ferramentas de secret scanning:** Adversários utilizam ferramentas especializadas para pesquisar automaticamente repositórios públicos em busca de padrões que indiquem segredos expostos. `truffleHog` analisa o histórico completo de commits de um repositório em busca de strings com alta entropia (características de chaves criptográficas e tokens). `gitleaks` usa regras configuráveis baseadas em regex para identificar padrões conhecidos de credenciais (AWS keys, GitHub tokens, Stripe API keys, senhas de banco de dados). `git-dumper` e `GitTools` podem ser usados para extrair repositórios .git expostos acidentalmente em servidores web. **GitHub Dorks (pesquisas avançadas na plataforma):** O GitHub Search oferece operadores avançados que permitem busca extremamente direcionada. Adversários constroem queries específicas como: - `org:empresa-alvo filename:.env password` - `user:desenvolvedor-alvo "aws_secret_access_key"` - `"empresa-alvo.com" "password" filename:config` - `"internal.empresa.com.br" token language:python` Essas queries retornam resultados imediatos e podem revelar credenciais ativas em segundos. O GitHub implementou verificação automática de segredos (Secret Scanning) para alguns padrões, mas a cobertura é incompleta e muitos padrões customizados de organizações brasileiras não são detectados. **Análise de histórico de commits:** Mesmo quando um arquivo com credenciais é removido de um repositório, ele permanece acessível no histórico de commits (`git log --all`). Adversários exploram isso sistematicamente, pois muitos desenvolvedores acreditam erroneamente que deletar um arquivo ou fazer um novo commit que o remova torna o segredo inacessível. A única forma de eliminar um segredo do histórico é reescrever o histórico com `git filter-branch` ou `BFG Repo-Cleaner` e fazer force push - operação que muitos desconhecem ou evitam por quebrar o histórico colaborativo. **Mapeamento de dependências e infraestrutura:** Além de segredos, adversários analisam arquivos de configuração de infraestrutura como código (`terraform/*.tf`, `kubernetes/*.yaml`, `docker-compose.yml`, `ansible/playbooks/`), que revelam a arquitetura completa dos sistemas internos, incluindo endereços IP internos, nomes de serviços, configurações de rede e provedor de cloud utilizado. **Identificação de desenvolvedores para ataques de engenharia social:** Commits em repositórios públicos expõem nomes e endereços de e-mail de contribuidores. Adversários como [[g1004-lapsus|LAPSUS$]] utilizaram essas informações para identificar desenvolvedores com acesso privilegiado e abordá-los diretamente com propostas de compra de credenciais ou via SIM swapping de seus celulares pessoais. ## Attack Flow ```mermaid graph TB A["Adversário define organização ou desenvolvedor-alvo"] --> B["Busca repositórios públicos associados"] B --> C1["GitHub Dorks: org:empresa filename:.env"] B --> C2["Varredura com truffleHog / gitleaks"] B --> C3["Análise de histórico de commits (git log)"] B --> C4["Análise de arquivos IaC (Terraform, Kubernetes)"] C1 --> D1["Credenciais hardcoded: API keys, senhas, tokens"] C2 --> D1 C3 --> D1 C4 --> D2["Mapa de infraestrutura: IPs, serviços, cloud provider"] D1 --> E1["Acesso direto via credenciais válidas: T1078"] D2 --> E2["Reconhecimento adicional direcionado: T1595"] E1 --> F1["Comprometimento de conta cloud (AWS, Azure, GCP)"] E1 --> F2["Acesso a sistemas internos via VPN/SSH"] E2 --> F3["Exploração de serviços expostos identificados"] F1 --> G["Impacto: exfiltração, ransomware, espionagem, sabotagem"] F2 --> G F3 --> G ``` ## Exemplos de Uso **LAPSUS$ - Modus operandi baseado em repositórios públicos (2021-2022):** O grupo [[g1004-lapsus|LAPSUS$]], predominantemente composto por adolescentes com sede no Brasil e no Reino Unido, tornou a busca em repositórios de código uma das pedras angulares de suas operações. O grupo comprometeu empresas como Microsoft, NVIDIA, Samsung, Okta, T-Mobile e Uber. Em vários casos, o acesso inicial foi obtido através de credenciais encontradas em repositórios GitHub públicos ou internos de desenvolvedores descuidados. O grupo também públicou no Telegram tutoriais sobre como usar GitHub Dorks para encontrar credenciais, demonstrando que a técnica é acessível mesmo para atacantes sem habilidades técnicas avançadas. **Contagious Interview - Reconhecimento em repositórios de candidatos a emprego:** A campanha [[g1052-contagious-interview|Contagious Interview]], atribuída ao [[g0032-lazarus-group|Lazarus Group]] norte-coreano, explora repositórios GitHub de desenvolvedores de software que são alvos de falsas ofertas de emprego. O grupo analisa os repositórios públicos dos candidatos para entender suas habilidades técnicas, identificar projetos em que trabalham, mapear empresas para as quais contribuem e encontrar possíveis segredos expostos. As informações coletadas são usadas para criar entrevistas técnicas altamente convincentes que levam à instalação de malware disfarçado de "desafio técnico" de programação. **HAFNIUM - Reconhecimento de infraestrutura Exchange via repositórios:** O [[g0125-silk-typhoon|HAFNIUM]] utilizou repositórios GitHub para pesquisar ferramentas de administração de Exchange Server, scripts de automação e configurações que revelavam arquiteturas internas de organizações-alvo. O grupo também monitorava repositórios de PoCs (Proofs of Concept) para novas vulnerabilidades Exchange, sendo frequentemente um dos primeiros a explorar CVEs recém-públicados com PoC disponível. **Vazamentos de credenciais de empresas brasileiras em repositórios públicos:** Estudos conduzidos por pesquisadores de segurança brasileiros identificaram padrões recorrentes de exposição: desenvolvedores de startups de fintechs e healthtechs frequentemente expõem chaves de API do PIX, tokens de acesso ao Open Banking, credenciais de bancos de dados PostgreSQL em RDS da AWS e tokens de serviços de nuvem em repositórios GitHub. Em alguns casos documentados, sistemas de pagamento foram comprometidos dentro de horas após a exposição de credenciais, evidênciando monitoramento automatizado por grupos criminosos. ## Detecção ```yaml title: Acesso Massivo a Repositórios GitHub Públicos de Organização status: experimental logsource: category: network product: firewall detection: selection_github_bulk: dst_hostname|contains: 'api.github.com' http_uri|contains: - '/search/code' - '/search/commits' - '/repos/' http_method: 'GET' timeframe: 1m condition: selection_github_bulk | count() by src_ip > 50 level: medium tags: - attack.reconnaissance - attack.t1593.003 ``` ```yaml title: Uso de Ferramenta de Secret Scanning em Repositório Corporativo status: experimental logsource: category: process_creation product: windows detection: selection_secret_tools: Image|endswith: - '\trufflehog.exe' - '\gitleaks.exe' - '\detect-secrets' CommandLine|contains: - 'github.com' - '--repo' - 'scan' condition: selection_secret_tools level: high tags: - attack.reconnaissance - attack.t1593.003 ``` ```yaml title: Clonagem em Massa de Repositórios Públicos da Organização status: experimental logsource: category: network product: proxy detection: selection_bulk_clone: cs-host: 'github.com' cs-uri-stem|endswith: '.git' cs-method: 'GET' filter_internal_ci: c-ip|cidr: - '10.0.0.0/8' - '172.16.0.0/12' - '192.168.0.0/16' timeframe: 10m condition: selection_bulk_clone and not filter_internal_ci | count() by c-ip > 10 level: low tags: - attack.reconnaissance - attack.t1593.003 ``` > [!warning] Detecção Proativa Recomendada > A abordagem mais eficaz é **proativa**: utilizar ferramentas como GitHub Secret Scanning (nativo), `gitleaks` em pipelines CI/CD e serviços de monitoramento de exposição (GitGuardian, SpectralOps) para detectar credenciais expostas antes que adversários as encontrem. Reagir após a exposição já é tarde - adversários com automação encontram credenciais em minutos após o commit. ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1013-application-developer-guidance\|M1013]] | Application Developer Guidance | Treinar desenvolvedores para nunca fazer commit de credenciais, chaves ou segredos. Implementar pre-commit hooks que bloqueiem commits com padrões de segredos. Usar gerenciadores de segredos (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) em vez de arquivos de configuração. | | [[m1047-audit\|M1047]] | Audit | Auditar regularmente repositórios públicos da organização em busca de exposições inadvertidas. Configurar alertas no GitHub Secret Scanning. Usar ferramentas como GitGuardian ou gitleaks em pipelines CI/CD para detectar segredos antes do merge. | > [!tip] Controles Adicionais de Alta Eficácia > - **Pre-commit hooks obrigatórios**: Implementar `pre-commit` com `detect-secrets` ou `gitleaks` como hook obrigatório em todas as estações de desenvolvimento. Isso impede o commit de segredos antes que cheguem ao repositório. > - **Política de repositórios privados por padrão**: Configurar a organização no GitHub para que novos repositórios sejam privados por padrão. Requireir aprovação explícita para tornar repositórios públicos. > - **Rotação imediata de segredos expostos**: Se uma credencial for exposta, assumir que já foi comprometida e rotacionar imediatamente - não apenas remover do repositório. O histórico de commits permanece acessível. > - **GitHub Advanced Security para organizações**: Habilitar Code Scanning, Secret Scanning e Dependency Review para todos os repositórios. O Secret Scanning detecta automaticamente padrões de mais de 200 tipos de segredos e envia alertas. > - **Segregação de ambientes**: Usar credenciais de desenvolvimento/staging completamente separadas das de produção. Assim, uma exposição em repositório de desenvolvimento não compromete sistemas produtivos. > - **Monitoramento contínuo de exposição**: Subscrever a serviços como GitGuardian ou SpectralOps que monitoram 24/7 toda atividade pública no GitHub em busca de padrões associados à organização. ## Contexto Brasil/LATAM O Brasil ocupa uma posição de destaque negativo no contexto de T1593.003, por razões que refletem o rápido crescimento do ecossistema de desenvolvimento de software sem o correspondente amadurecimento das práticas de segurança: **Explosão de startups sem cultura de segurança:** O ecossistema de startups brasileiro cresceu exponencialmente na última década, com hubs em São Paulo, Florianópolis, Belo Horizonte e Recife. Startups em estágio inicial frequentemente priorizam velocidade de desenvolvimento sobre segurança, resultando em práticas como: repositórios públicos para facilitar colaboração, credenciais hardcoded para "facilitar o deploy" e uso de chaves de produção em ambientes de desenvolvimento. Pesquisas indicam que repositórios de fintechs e healthtechs brasileiras são particularmente prolíficos em exposições de credenciais de APIs bancárias e sistemas de saúde. **LAPSUS$ como caso emblemático brasileiro:** O grupo [[g1004-lapsus|LAPSUS$]] tem raízes documentadas no Brasil - líderes identificados operavam do Rio de Janeiro e de São Paulo. O sucesso do grupo em comprometer dezenas de empresas globais usando primariamente técnicas de reconhecimento em repositórios e engenharia social demonstrou que essa abordagem é altamente eficaz e replicável. Grupos de cibercrime local adotaram as táticas do LAPSUS$ direcionando-as a empresas brasileiras de médio e grande porte. **Setor público e licitações com código exposto:** Órgãos governamentais brasileiros frequentemente públicam código-fonte de sistemas em repositórios públicos por requisitos de transparência ou contratações via licitação pública. Esses repositórios frequentemente contêm credenciais de ambientes de homologação que são idênticas às de produção, configurações de infraestrutura e documentação de APIs internas. A busca em repositórios de `gov.br` no GitHub revela consistentemente exposições que não são reportadas por ausência de processos de monitoramento. **Open Banking e PIX como alvos de alto valor:** Com a expansão do Open Banking e a ubiquidade do PIX no Brasil, credenciais de APIs bancárias têm altíssimo valor para grupos de fraude financeira. Desenvolvedores de sistemas de integração bancária frequentemente expõem tokens de sandbox que, em muitos casos, funcionam também em produção ou revelam padrões de autenticação que facilitam a descoberta de credenciais produtivas. ## Referências - **Técnica pai:** [[t1583-001-domains|Domains]] - **Técnica relacionada (repositórios privados):** [[t1213-003-code-repositories|T1213.003 - Code Repositories (Collection)]] - **Técnicas complementares de reconhecimento:** [[t1592-002-software|T1592.002 - Software]], [[t1596-search-open-technical-databases|T1596 - Search Open Technical Databases]], [[t1598-phishing-for-information|T1598 - Phishing for Information]] - **Técnicas habilitadas por credenciais encontradas:** [[t1078-valid-accounts|T1078 - Valid Accounts]], [[t1566-phishing|T1566 - Phishing]], [[t1586-compromise-accounts|T1586 - Compromise Accounts]] - **Técnicas de comprometimento de infraestrutura:** [[t1584-compromise-infrastructure|T1584 - Compromise Infrastructure]] - **Grupos que utilizam:** [[g1004-lapsus|LAPSUS$]], [[g1052-contagious-interview|Contagious Interview]], [[g0125-silk-typhoon|HAFNIUM]], [[g0032-lazarus-group|Lazarus Group]] - **Mitigações:** [[m1013-application-developer-guidance|M1013 - Application Developer Guidance]], [[m1047-audit|M1047 - Audit]] --- *Fonte: [MITRE ATT&CK - T1593.003](https://attack.mitre.org/techniques/T1593/003)*