# T1590.001 - Domain Properties ## Descrição **Domain Properties** (Coleta de Propriedades de Domínio) é uma sub-técnica da tática de [[t1590-gather-victim-network-information|Coleta de Informações de Rede da Vítima]] (T1590) na qual adversários coletam informações abrangentes sobre os domínios de internet registrados por um alvo. Esse reconhecimento ocorre inteiramente fora do ambiente da vítima e utiliza fontes de dados públicas ou semi-públicas, tornando-o extremamente difícil de detectar e mitigar. As propriedades de domínio que os adversários buscam incluem uma ampla variedade de dados: domínios e subdomínios registrados pela organização, informações de registro WHOIS (nome do registrante, organização, endereço, e-mail de contato, número de telefone, datas de criação e expiração), servidores de nomes (NS records), servidores de e-mail (MX records), registros SPF, DKIM e DMARC que revelam a infraestrutura de e-mail, certificados TLS/SSL e seus metadados, e histórico de registros DNS. Quando provedores de nuvem de terceiros estão em uso, endpoints de API públicamente acessíveis como **GetUserRealm** e **autodiscover** em ambientes Office 365/Microsoft 365 podem revelar o tenant de nuvem associado ao domínio, a configuração de federação de identidade (ADFS, Okta, Azure AD) e até o tipo de licença Microsoft em uso. O [[g0034-sandworm|Sandworm Team]] (APT28/Fancy Bear é um grupo distinto; Sandworm é atribuído ao GRU russo) é documentado usando coleta extensiva de propriedades de domínio como precursor de campanhas de phishing altamente direcionadas e comprometimento de infraestrutura. As informações coletadas habilitam ataques subsequentes: e-mails de contato obtidos via WHOIS alimentam campanhas de [[t1566-phishing|Phishing]] (T1566); servidores de nomes identificados podem ser alvos de comprometimento via [[t1584-compromise-infrastructure|Compromisso de Infraestrutura]] (T1584); e a estrutura de domínios pode revelar fornecedores de serviços e parceiros que se tornam alvos de ataque de cadeia de suprimentos. A disponibilidade de dados históricos de WHOIS e DNS por meio de serviços como DomainTools, SecurityTrails e PassiveDNS amplifica o poder dessa técnica, permitindo que atacantes reconstruam a evolução da infraestrutura de uma organização ao longo do tempo, identificando ativos esquecidos, domínios expirados reutilizáveis e padrões de nomenclatura internos. > **Técnica pai:** [[t1590-gather-victim-network-information|T1590 - Gather Victim Network Information]] > **Tática MITRE:** Reconnaissance > **Plataforma:** PRE (pré-comprometimento) --- ## Como Funciona ### Coleta via WHOIS O protocolo WHOIS é a fonte primária de informações de domínio. Adversários consultam registros WHOIS diretamente ou por meio de agregadores: ```bash # Consulta direta whois empresa-alvo.com.br # Campos de interesse: # Registrant Name, Organization, Email # Name Servers # Creation Daté, Expiration Daté # Registrar: (identifica possível alvo para comprometimento) ``` Para domínios `.br`, o **Registro.br** (NIC.br) mantém o WHOIS centralizado em `registro.br/whois/`. A política de privacidade de WHOIS do Brasil não oculta dados de pessoas jurídicas, tornando organizações corporativas especialmente vulneráveis. ### Enumeração de Registros DNS Além do WHOIS, adversários enumeram registros DNS para mapear a infraestrutura técnica: ```bash # Consulta de registros MX (infraestrutura de e-mail) dig MX empresa-alvo.com.br # Consulta de registros NS (servidores de nomes) dig NS empresa-alvo.com.br # Consulta de registros TXT (SPF, DKIM, verificação de domínio) dig TXT empresa-alvo.com.br # Zone transfer (se mal configurado) dig axfr empresa-alvo.com.br @ns1.empresa-alvo.com.br ``` Registros TXT SPF frequentemente revelam provedores de e-mail terceirizados (Sendgrid, Mailchimp, HubSpot), sistemas de CRM em uso e intervalos de IP autorizados. ### Coleta via APIs de Nuvem - Microsoft 365 Para organizações usando Microsoft 365, endpoints públicos revelam informações valiosas sem autenticação: ```bash # Detectar tenant Microsoft 365 curl "https://login.microsoftonline.com/{dominio}.com.br/.well-known/openid-configuration" # GetUserRealm - revela se o domínio usa ADFS, Azure AD ou ambos curl "https://login.microsoftonline.com/[email protected]&xml=1" # Autodiscover - revela configuração de Exchange/O365 curl "https://autodiscover.empresa.com.br/autodiscover/autodiscover.xml" ``` A ferramenta [[s0677-aadinternals|AADInternals]] automatiza essa coleta, extraindo o tipo de autenticação configurado, se há integração com Okta ou ADFS, o nome do tenant Azure AD e metadados de configuração de identidade. ### Análise de Certificados TLS Plataformas como **crt.sh** e **Censys** indexam certificados TLS emitidos, revelando subdomínios que não aparecem em DNS público: ``` https://crt.sh/?q=%25.empresa-alvo.com.br ``` Certificados wildcard expirados, subdomínios de staging (`dev.`, `test.`, `uat.`) e sistemas internos expostos acidentalmente são frequentemente descobertos por essa via. --- ## Attack Flow ```mermaid graph TB A["Identificação do Alvo<br/>(Nome da organização, CNPJ)"] --> B["Consulta WHOIS<br/>(registro.br, ARIN, RIPE)"] A --> C["Enumeração DNS<br/>(dig, nslookup, dnsrecon)"] A --> D["Análise de Certificados TLS<br/>(crt.sh, Censys)"] B --> E["Dados de Contato<br/>(e-mails, telefones, endereços)"] B --> F["Registradores e NS<br/>(infraestrutura de domínio)"] C --> G["Registros MX/SPF/TXT<br/>(infraestrutura de e-mail)"] C --> H["Subdomínios<br/>(staging, dev, admin)"] D --> I["Subdomínios Ocultos<br/>(certificados históricos)"] E --> J["Phishing Direcionado<br/>(T1566)"] F --> K["Comprometimento de NS<br/>(T1584)"] G --> L["Engenharia Social<br/>(spoofing de e-mail)"] H --> M["Varredura de Ativos<br/>(T1595)"] I --> M J --> N["Acesso Inicial"] K --> N L --> N M --> N ``` --- ## Exemplos de Uso ### Sandworm Team - Campanhas de Sabotagem e Espionagem O [[g0034-sandworm|Sandworm Team]], unidade de ciberespionagem e sabotagem do GRU (serviço de inteligência militar russo), é documentado usando coleta extensiva de propriedades de domínio como fase preparatória de campanhas contra infraestrutura crítica. Em operações como a que resultou no ataque NotPetya (2017) e em campanhas contra a Ucrânia, o Sandworm mapeou domínios de organizações alvo para identificar servidores de e-mail, infraestrutura de atualização de software e relacionamentos de fornecedores - informações que habilitaram ataques à cadeia de suprimentos. ### AADInternals - Reconhecimento de Microsoft 365 A ferramenta [[s0677-aadinternals|AADInternals]], desenvolvida pelo pesquisador finlandês Dr. Nestori Syynimaa, é amplamente utilizada em operações de red team e, documentadamente, por atores maliciosos para coletar informações sobre tenants Microsoft 365 sem autenticação. A ferramenta pode determinar se uma organização usa autenticação federada (ADFS), identificar o provedor de identidade configurado e até verificar se determinados endereços de e-mail são válidos no tenant. ### Cenários de Ataque a Organizações Brasileiras **Setor Financeiro:** Bancos e fintechs brasileiras registradas no Banco Central frequentemente possuem múltiplos domínios (corporate, api, internet banking) cujas propriedades revelam a pilha tecnológica completa. Adversários mapeiam registros SPF para identificar provedores de e-mail transacional, que podem ser alvo de comprometimento para envio de phishing autenticado. **Governo:** Órgãos governamentais brasileiros usam domínios `.gov.br` gerenciados pelo SERPRO. A estrutura de domínios governamentais é parcialmente pública e permite identificar sistemas de missão crítica como o Portal da Transparência, sistemas de licitação e portais de acesso ao cidadão. **Ataques a Cadeia de Suprimentos:** Adversários coletam propriedades de domínio de fornecedores e parceiros de uma organização alvo, buscando elos mais fracos. Um domínio `.com.br` de fornecedor de TI com infraestrutura de e-mail desatualizada pode ser comprometido para enviar phishing interno confiável ao alvo principal. --- ## Detecção A detecção de coleta de Domain Properties é extremamente limitada, pois a maioria das consultas ocorre em sistemas públicos (WHOIS, DNS, crt.sh) fora do controle da organização. A detecção viável se concentra em consultas anômalas aos próprios sistemas. ### Regra Sigma - Consultas WHOIS Anômalas ```yaml title: "Domain Properties - Consultas WHOIS em Volume" status: experimental description: | Detecta consultas WHOIS de alto volume originadas de um único endereço IP, possívelmente indicando reconhecimento automatizado de propriedades de domínio. logsource: category: network service: dns detection: selection: query_type: "TXT" query_name|endswith: - ".br" - ".com.br" - ".gov.br" - ".org.br" timeframe: 300s condition: selection | count(src_ip) by src_ip > 200 level: medium tags: - attack.reconnaissance - attack.t1590.001 falsepositives: - Ferramentas de monitoramento DNS legítimas - Scanners de segurança internos autorizados ``` ### Regra Sigma - Consultas AADInternals / GetUserRealm ```yaml title: "Domain Properties - Consulta GetUserRealm Microsoft 365" status: experimental description: | Detecta consultas ao endpoint GetUserRealm do Microsoft, frequentemente utilizado por ferramentas de reconhecimento como AADInternals para mapear configurações de autenticação de tenants Azure AD/Office 365. logsource: product: azure service: signinlogs detection: selection: operationName: "Get User Realm" resultType: "0" timeframe: 60s condition: selection | count(callerIpAddress) by callerIpAddress > 20 level: high tags: - attack.reconnaissance - attack.t1590.001 - attack.t1589.002 falsepositives: - Ferramentas legítimas de monitoramento de identidade - Clientes de e-mail configurando autodiscover ``` ### Indicadores de Comprometimento Comportamentais | Indicador | Descrição | Severidade | |-----------|-----------|-----------| | Zone transfer bem-sucedido | Transferência de zona DNS aceita por servidor externo | Crítica | | Múltiplas consultas GetUserRealm | > 20 consultas de IP externo em 1 minuto | Alta | | Consultas autodiscover de IPs suspeitos | Requisições ao endpoint autodiscover de fora da rede corporativa | Média | | Pico em consultas crt.sh | Não detectável diretamente - monitorar via threat intel | Baixa | | Histórico WHOIS consultado | Indicador fraco - usar como contexto em investigação | Baixa | --- ## Mitigação | ID | Mitigação | Descrição | |----|-----------|-----------| | [[m1056-pre-compromise\|M1056]] | Pre-compromise | A principal mitigação é reduzir a quantidade de informação publicamente disponível sobre domínios da organização. Usar proteção de privacidade WHOIS onde disponível (limitado para domínios `.br` de pessoas jurídicas). Revisar regularmente registros DNS públicos e remover entradas desnecessárias. Auditar certificados TLS emitidos via crt.sh e revogar certificados de subdomínios não mais em uso. | ### Controles Preventivos Adicionais 1. **Privacidade WHOIS:** Para domínios `.com` internacionais, usar serviços de privacidade de registrante para ocultar dados pessoais de contato. Para `.com.br`, a exposição de dados de CNPJ é obrigatória - focar em usar endereços de e-mail genéricos ([email protected]) em vez de e-mails pessoais. 2. **Monitoramento de Domínios Similares:** Usar serviços de monitoramento como DomainTools Iris ou RiskIQ para detectar registro de domínios similares (typosquatting) que podem ser usados em campanhas de phishing - ex: `empresa-alvo.com.br` → `empresa-al-vo.com.br`. 3. **Endurecimento de DNS:** - Desabilitar zone transfers públicos (`allow-transfer { none; };` no BIND) - Implementar DNSSEC para prevenir envenenamento de cache - Remover registros DNS obsoletos (subdomínios de sistemas desativados) 4. **Monitoramento de Microsoft 365:** Habilitar logs de auditoria no Azure AD para detectar consultas anômalas a endpoints de descoberta. Configurar alertas no Microsoft Defender para Identity para consultas GetUserRealm em volume. 5. **Inventário de Certificados:** Manter inventário atualizado de todos os certificados TLS emitidos. Usar ferramentas como Let's Encrypt Certificaté Transparency ou Sectigo Monitor para ser alertado sobre novos certificados emitidos para subdomínios da organização. --- ## Contexto Brasil/LATAM A coleta de Domain Properties é particularmente relevante no contexto brasileiro dado o ecossistema de nomes de domínio `.br` gerenciado pelo NIC.br/Registro.br. ### Características Únicas do Ecossistema `.br` **WHOIS do Registro.br:** O Brasil mantém um sistema WHOIS centralizado para domínios `.br`. Diferente de domínios `.com` internacionais, registros de pessoas jurídicas brasileiras com domínios `.gov.br`, `.edu.br`, `.mil.br` e `.org.br` expõem públicamente CNPJ, endereço completo e contatos técnicos e administrativos - informações valiosas para engenharia social e spear phishing. **Fragmentação de Domínios:** Organizações brasileiras frequentemente registram variações de domínio (`.com.br`, `.com`, `.net.br`, `.org.br`) sem necessáriamente gerenciar todas ativamente. Domínios expirados ou abandonados representam oportunidade para domain takeover, permitindo que atacantes hospedem conteúdo malicioso em domínios que mantêm reputação histórica positiva. **Open Finance e PIX:** Com a expansão do Open Finance no Brasil, organizações financeiras passaram a registrar domínios específicos para APIs regulatórias (ex: `openbanking.banco.com.br`). A coleta de propriedades desses domínios pode revelar infraestrutura de API financeira crítica - endereços IP de servidores de API, provedores de CDN em uso e arquitetura de autenticação. ### Grupos de Ameaça com Histórico LATAM O [[g0034-sandworm|Sandworm Team]] tem histórico documentado de operações que afetam aliados e parceiros estratégicos do Brasil. Grupos de ameaça com foco em espionagem industrial - como atores vinculados à China que operam contra o setor de energia e telecomúnicações - utilizam extensivamente coleta de Domain Properties como parte de reconhecimento de longo prazo antes de campanhas direcionadas ao setor corporativo brasileiro. Grupos de ransomware como [[lockbit|LockBit]] e afiliados de [[blackcat|ALPHV]] também utilizam Domain Properties para identificar fornecedores de MSP (Managed Service Providers) brasileiros, que se tornam alvos de comprometimento para atingir múltiplos clientes corporativos simultaneamente. ### Recomendações Específicas para Organizações Brasileiras 1. Registrar variações de domínio (`.com`, `.com.br`, `.net.br`) preventivamente e apontar para página de alerta 2. Monitorar crt.sh semanalmente para novos certificados emitidos para subdomínios da organização 3. Usar e-mails de role (`abuse@`, `security@`, `registros@`) nos registros WHOIS em vez de e-mails pessoais de funcionários 4. Implementar DMARC com política `reject` para prevenir spoofing de e-mail usando propriedades de domínio coletadas --- ## Referências - [MITRE ATT&CK - T1590.001](https://attack.mitre.org/techniques/T1590/001) - [Registro.br - WHOIS](https://registro.br/tecnologia/ferramentas/whois/) - [crt.sh - Certificaté Transparency Search](https://crt.sh/) - [SecurityTrails - Historical DNS Data](https://securitytrails.com/) - [AADInternals - Dr. Nestori Syynimaa](https://o365blog.com/aadinternals/) - [Microsoft - GetUserRealm Endpoint](https://docs.microsoft.com/en-us/azure/active-directory/develop/userinfo) - [[t1590-gather-victim-network-information|T1590 - Gather Victim Network Information]] - [[t1596-002-whois|T1596.002 - WHOIS]] - [[t1595-active-scanning|T1595 - Active Scanning]] - [[t1566-phishing|T1566 - Phishing]] - [[t1584-compromise-infrastructure|T1584 - Compromise Infrastructure]] - [[g0034-sandworm|Sandworm Team]] - [[s0677-aadinternals|AADInternals]]