# 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]]