Recomendações para Notificações de Incidentes de Segurança

1. Importância da notificação de incidentes de segurança

Parte indispensável do processo de tratamento de incidentes, a notificação é uma atividade de grande importância visto que:

• Melhora a capacidade de detecção de incidentes. Muitas instituições descobrem que estão comprometidas apenas quando são notificadas por terceiros¹. Notificar incidentes pode ajudar a identificar problemas e prevenir novas ocorrências;
• Contribui para a segurança geral da Internet. Ao notificar uma tentativa de ataque da qual foi vítima, ao invés de apenas mitigá-la, busca-se a solução do problema e demonstra-se comprometimento com questões de segurança;
• Pode ajudar a conter danos e prejuízos. Notificações podem ser instrumentos eficazes na mitigação de incidentes e na contenção dos prejuízos, como por exemplo, em casos de fraudes;
• Permite gerar estatísticas, correlacionar dados e identificar tendências que ajudarão a elaborar recomendações e materiais de apoio, a orientar campanhas pela adoção de boas práticas e a estabelecer ações em cooperação.

Este documento tem por objetivo reunir boas práticas para a notificação de incidentes de segurança em computadores e redes, visando sua eficácia.

(1) De acordo com o relatório da Mandiant "M-Trends® 2021: Special Report", 41% das instituições vítimas de comprometimento souberam do problema por meio de notificação recebida de entidade externa.[ voltar ]

2. O que notificar

Devem ser notificados eventos adversos relacionados à segurança dos sistemas de computação ou das redes de computadores, em desrespeito à política de segurança ou à política de uso aceitável da organização, como por exemplo:

• tentativas, com ou sem sucesso, de ganhar acesso não autorizado a um sistema ou a seus dados (ex: varreduras, ataques de força bruta SSH);
• interrupção indesejada de serviço (ex: ataque de negação de serviço);
• uso não autorizado de um sistema (ex: site comprometido hospedando páginas de phishing, propagando malware ou infectado com bot para ataque a terceiros/envio de spam);
• modificações em um sistema sem o conhecimento ou consentimento prévio de seu dono (ex: desfiguração de página);
• sistemas desatualizados ou incorretamente configurados, permitindo abuso (ex: DNS recursivo aberto, NTP permitindo amplificação);
• uso abusivo, em desrespeito à política de uso aceitável do provedor de serviço (ex: contratação de sistema em nuvem para uso malicioso).

3. A quem notificar

Enviar a notificação aos contatos apropriados é fundamental para não retardar seu processamento ou, ainda pior, seu descarte. A seleção criteriosa dos contatos é igualmente importante a fim de evitar que a notificação seja remetida ao próprio atacante ou fraudador, para não alertá-lo.

De maneira geral, devem ser notificados os responsáveis pelo equipamento que originou a atividade maliciosa e também os CSIRTs/contatos de abuso das redes envolvidas. Todavia, a escolha dos contatos apropriados pode variar em razão das características do incidente.

Os exemplos abaixo, apesar de não comporem uma lista exaustiva, ilustram a variação de contatos conforme o tipo do incidente:

• Scan de rede, tentativas de ganhar acesso não autorizado, tentativa de exploração de vulnerabilidade para execução de código remoto: utilizar o contato do responsável pela rede e/ou AS do qual o endereço IP, identificado nos logs do ataque, faz parte;
  
  
• Página maliciosa hospedada em website legítimo comprometido: caso típico de página de phishing ou de página para download/execução de código malicioso, hospedada em website de natureza não maliciosa (ex: sites de notícias, de compras, de entretenimento, de governo, etc.), mas que foi comprometido pelo atacante/fraudador. Utilizar o contato do responsável pela rede e/ou AS do qual o endereço IP do website faz parte e, se disponível, o contato do responsável pelo domínio;
  
  
• Página maliciosa utilizando domínio malicioso: caso típico de página de phishing ou de página para download/execução de código malicioso, hospedada em website de natureza maliciosa, por exemplo, cujo nome do domínio se assemelha ao domínio da instituição referenciada na fraude e, em geral, registrado há pouco tempo. Neste caso NÃO se recomenda utilizar o contato de domínio (da URL da página) pois, provavelmente, é do próprio fraudador. Deve-se utilizar o contato do responsável pela rede e/ou AS do qual o endereço IP do website faz parte e o contato da entidade registradora do domínio (Registrar);
  
  
• DNS mal configurado permitindo abuso: caso típico de DNS recursivo aberto. Utilizar o contato do responsável pela rede e/ou AS do qual o IP do DNS faz parte. Se disponível, incluir o contato do administrador do DNS (em geral encontrado no registro SOA do DNS);
  
  
• DNS malicioso hospedado em provedor de hospedagem/nuvem (rogue DNS) ou DNS comprometido: são dois casos típicos, um em que o fraudador instala servidor malicioso em infraestrutura de terceiros, em geral provedor de serviços de hospedagem ou de nuvem, e outro em que um servidor DNS legítimo é comprometido e sua configuração é adulterada para gerar respostas maliciosas (ex: respostas autoritativas para zonas que não são de sua administração). Em ambos os casos, recomenda-se utilizar o contato do responsável pela rede e/ou AS do qual o IP do DNS faz parte;
  
  
• Ataque de negação de serviço (DDoS): dependendo das características do ataque, pode não ser possível identificar e notificar seus responsáveis, de forma que uma análise minuciosa do incidente deve ser conduzida. Duas situações típicas são:
  • as evidências permitem identificar os IPs participantes, por exemplo, em ataque direto por bots sem spoofing de endereços. Neste caso notificam-se os responsáveis pelas redes e/ou ASNs dos quais os IPs atacantes (bots) fazem parte;
  • não é possível a identificação dos IPs que originaram o ataque, por exemplo, em ataque indireto via requisições com endereço adulterado (spoofing) disparadas a serviços abertos/mal configurados, gerando amplificação contra terceiro (alvo do ataque). Recomenda-se notificar os responsáveis pelos computadores que foram abusados para gerar a amplificação, a fim de que corrijam as vulnerabilidades que possibilitaram o abuso pelo atacante (ex: DNS recursivo aberto, NTP permitindo "monlist", SNMP aberto, serviço CHARGEN ativo e aberto, rede permitindo spoofing, etc.);
• Vazamento de dados pessoais (PII): caso típico de dados pessoais (ex: endereço e-mail, nomes de familiares, números de documentos, de conta bancária, de cartão de crédito, etc.) divulgados na Internet e obtidos a partir de servidores ou redes comprometidos. Dependendo da natureza dos dados divulgados, devem ser notificados os contatos das redes (a rede de onde os dados foram extraídos e a rede na qual os dados foram publicados), os contatos de CSIRTs das demais instituições envolvidas (ex: bancos, operadoras de cartão de crédito, etc.) e o contato do domínio do site usado para divulgação dos dados, desde que seja evidente que o domínio não é malicioso.
  

Em todos os casos, se houver um contato de CSIRT para rede/AS/domínio, este deve ser incluído na notificação, bem como o(s) contato(s) do(s) CSIRT(s) de responsabilidade nacional deve(m) ser incluído(s) em cópia.

Caso algum dos domínios ou redes envolvidos seja brasileiro, mantenha sempre o CERT.br (cert@cert.br) na cópia da mensagem. Reclamações de spam devem ser encaminhadas exclusivamente para o endereço <mail-abuse@cert.br>.

Nos casos de incidentes envolvendo a Administração Pública Federal Brasileira (.gov.br) deve-se incluir também o Centro de Tratamento de Incidentes de Segurança de Redes de Computadores da Administração Pública Federal - CTIR Gov (ctir@ctir.gov.br).

4. Buscando contatos

Não existe uma fonte única de busca para informações de contatos, seja para recursos de números (IP/ASN), de domínios ou de grupos de resposta a incidentes. Seguem abaixo algumas referências relevantes.

4.1. WHOIS e RDAP

4.1.1. WHOIS

Uma das principais fontes de pesquisa para dados de contatos de redes, domínios, ASs, é o serviço de WHOIS. Não existe uma base de dados única global e, dependendo do cliente WHOIS utilizado, pode ser necessário especificar o servidor WHOIS exato a ser consultado. Algumas ferramentas online podem facilitar a busca e a identificação do servidor WHOIS mantenedor dos registros.

Dos campos de contato disponíveis nos registros WHOIS, o contato "abuse" é quem deve ser notificado. Na ausência do "abuse", o contato técnico é o mais apropriado.

Em virtude da falta de padronização na estrutura de dados do WHOIS, outros campos, até mesmo comentários, podem conter dados relacionados a contatos de segurança/abuso. Informações complementares podem ser encontradas na seção 7. Exemplos de consultas WHOIS e RDAP.

Seguem abaixo alguns endereços úteis de serviços de WHOIS:

• Para redes e domínios no Brasil (.br)
  • servidor WHOIS: whois.registro.br
  • interface Web: https://registro.br/tecnologia/ferramentas/whois/
• Registros Regionais da Internet (Regional Internet Registries ­ RIRs): são organizações responsáveis pela distribuição e gerenciamento dos recursos de números Internet (IPs e ASNs) para uma determinada região do mundo. Cada RIR possui sua própria base de dados e seu próprio serviço WHOIS para consulta às informações referentes a suas respectivas regiões de serviço.
  
  Para facilitar as consultas, o LACNIC e o APNIC implantaram o serviço Joint Whois, o qual funciona como ponto único de consulta a dados de qualquer RIR. O sistema é essencialmente um "proxy" que encaminha as consultas recebidas para o servidor WHOIS do RIR responsável e retorna a resposta final ao usuário.
  
  Os serviços WHOIS de cada RIR podem ser consultados em:
  
  
  • AfriNIC (África e partes do oceano Índico)
    • servidor WHOIS: whois.afrinic.net
    • interface Web: https://www.afrinic.net/whois
  • APNIC (Ásia/Pacífico)
    • servidor WHOIS: whois.apnic.net
    • interface Web: https://wq.apnic.net/static/search.html
  • ARIN (América do Norte e partes do Caribe)
    • servidor WHOIS: whois.arin.net
    • interface Web: https://whois.arin.net/ui
  • LACNIC (América Latina e partes do Caribe)
    • servidor WHOIS: whois.lacnic.net (também é Joint Whois)
    • interface Web: https://lacnic.net/cgi-bin/lacnic/whois
  • RIPE NCC (Europa, Oriente Médio e Ásia Central)
    • servidor WHOIS: whois.ripe.net
    • interface Web: https://apps.db.ripe.net/db-web-ui/query
• IANA (Internet Assigned Numbers Authority) é a responsável pela coordenação do conjunto global de endereços IPs e ASNs e a alocação destes recursos para os RIRs. É também quem opera vários aspectos importantes do DNS, incluindo a zona raiz.
  • servidor WHOIS: whois.iana.org
  • interface Web: https://www.iana.org/whois
• Ferramentas para redes conectadas à Internet em todas as regiões:
  • Geektools: ferramenta (proxy WHOIS) que permite consultar dados de registro de redes, domínios e ASNs, bem como identificar o servidor de WHOIS específico.
    • servidor WHOIS: whois.geektools.com
    • interface Web: http://www.geektools.com/whois.php
  • Team Cymru: oferece um serviço de mapeamento de IP para ASN e prefixos BGP.
    • https://team-cymru.com/community-services/ip-asn-mapping/
    • servidor WHOIS: whois.cymru.com e peer.whois.cymru.com
    • interface Web: https://asn.cymru.com/
  • Merit RADB: prove informações coletadas de todos os Registries que fazem parte do Internet Routing Registry. Os registros coletados fornecem informações sobre a maioria das redes e ASNs roteados na Internet.
    • servidor WHOIS: whois.radb.net
    • interface Web: https://www.radb.net/query/

É comum que as bases de WHOIS contenham dados defasados, visto que depende de cada instituição manter seu próprio registro atualizado. Por conseguinte, é também comum que os CSIRTs recebam respostas à notificações enviadas, informando que o contato referente a tal rede ou domínio mudou. Nestes casos, recomenda-se orientar a instituição para que promova a atualização dos dados de contatos junto à entidade que mantém seus registros e dados de WHOIS.

Exemplos de buscas em bases de dados WHOIS podem ser encontradas a partir da seção 7.1. Considerações no uso do WHOIS.

4.1.2. RDAP

O protocolo RDAP (Registration Data Access Protocol) é um padrão desenvolvido pelo Internet Engineering Task Force (IETF) para ser o sucessor do WHOIS na consulta de informações de registro dos Regional Internet Registries (RIRs) e de Domain Name Registries (DNRs). Ele busca corrigir deficiências do WHOIS, tratando questões como:

• padronização no formato de requisições, respostas e mensagens de erro;
• capacidade de bootstrapping e redirecionamento (usando os códigos de redirecionamento HTTP);
• suporte a segurança (autenticação, autorização, confidencialidade);
• suporte a caracteres especiais e múltiplos idiomas.

Bootstrapping (auto-inicialização, numa tradução livre) é o processo de determinar qual servidor RDAP é autoritativo para responder uma consulta, no contexto do escopo solicitado (nome de domínio, endereço IP ou número de sistema autônomo).

O RDAP emprega o conceito de serviços RESTful, baseando-se no protocolo HTTP/HTTPS para comunicação e no formato JSON para estrutura das respostas, o que facilita o parsing automatizado das informações. As consultas usam URIs específicas para pesquisar os diferentes recursos:

Recurso 		                      URI
==================================================================
Domínio                                       /domain/<FQDN>

Entidade (organização, titular, contato)      /entity/<ID>

Sistema	Autônomo                              /autnum/<ASN>

IP                                            /ip/<ip>

Bloco IP                                      /ip/<prefixo>/<cidr>

As especificações básicas do protocolo RDAP são referenciadas como STD 95 do IETF, que é composto pelas RFCs 7480, 7481, 9082, 9083 e 9224.

Informações complementares e atualizações podem ser encontradas nas RFCs 7485 e 8521 (BCP 221).

O serviço de consulta via RDAP já está disponível em todos os RIRs e em alguns ccTLDs/NIRs (National Internet Registries), dentre eles o .br (NIC.br/Registro.br). O serviço é obrigatório para gTLDs.

Dentre os serviços RDAP disponíveis, destacam-se:

• AfriNIC (África e partes do oceano Índico)
  • servidor RDAP: https://rdap.afrinic.net/rdap
• APNIC (Ásia/Pacífico)
  • servidor RDAP: https://rdap.apnic.net/
• ARIN (América do Norte e partes do Caribe)
  • servidor RDAP: https://rdap.arin.net/registry/
  • servidor bootstrap: https://rdap.arin.net/bootstrap/
  • cliente Web: https://search.arin.net/rdap/
  • cliente linha de comando: https://github.com/arineng/nicinfo
• LACNIC (América Latina e partes do Caribe, com bootstrap)
  • servidor RDAP: https://rdap.lacnic.net/rdap/
  • cliente Web: https://rdap-web.lacnic.net/
• NIC.br/Registro.br (Brasil)
  • servidor RDAP: https://rdap.registro.br/
  • cliente linha de comando: https://github.com/registrobr/rdap-client
• RIPE NCC (Europa, Oriente Médio e Ásia Central)
  • servidor RDAP: https://rdap.db.ripe.net/
• ICANN (apenas para domínios)
  • servidor RDAP: https://lookup.icann.org/
• RDAP.org (apenas servidor /bootstrapping/ - não é autoritativo para nenhum recurso)
  • servidor bootstrap: https://rdap.org/
  • cliente Web: https://client.rdap.org/

Para facilitar a identificação dos servidores RDAP autoritativos referentes à diferentes recursos e permitir o bootstrapping, a IANA mantém listas das URLs base dos serviços, conforme o tipo de recursos, em:

• https://data.iana.org/rdap/

Exemplos de buscas usando o protocolo RDAP podem ser encontradas a partir da seção 7.7. Considerações no uso do RDAP.

4.2. CSIRTs

Algumas fontes de consulta para contatos de CSIRTs são:

• Contatos de CSIRTs brasileiros:
  https://cert.br/csirts/brasil/
  
  
• Contatos de CSIRTs mundiais:
  • CSIRTs com responsabilidade nacional:
    https://www.sei.cmu.edu/our-work/cybersecurity-center-development/national-csirts/
    
    
  • CSIRTs membros do FIRST (Forum of Incident Response and Security Teams):
    https://www.first.org/members/teams/
    
    
  • CSIRTs da América Latina:
    https://csirt.lacnic.net/csirts-de-la-region
    
    
  • CSIRTs participantes do Trusted Introducer (maioria Europeus):
    https://www.trusted-introducer.org/directory/
    
    
  • CSIRTs da Ásia e Oceania membros do APCERT:
    https://www.apcert.org/about/structure/members.html
    
    

4.3. Top-Level Domains (TLDs)

Para contatos relacionados aos Top-Level Domains (TLDs), e em especial para os novos gTLDs registrados a partir de 2012, pode-se pesquisar informações via a página da IANA:

• https://www.iana.org/domains/root/db

Para cada um dos domínios listados na página, é possível verificar dados da delegação do domínio, tais como organização responsável, contato administrativo, contato técnico e, em "Registry Information", pode-se obter outros dados de contato bem como informações sobre o servidor WHOIS.

Em geral, os novos gTLDs possuem também uma página com informações para contato cujo endereço segue o formato padrão http://nic.gTLD. Por exemplo: para o gTLD .rio, a página é https://nic.rio.

Todos os novos gTLDs devem ter uma política para tratamento de abuso definida em seu documento de Política de Registro, que especifique canais de atendimento eletrônicos e postais.

4.4. Criando e mantendo base de contatos própria

É importante que os CSIRTs criem e atualizem continuamente sua própria base de dados à medida que forem tomando conhecimento de contatos mais apropriados àqueles indicados nas bases WHOIS, especialmente para instituições relevantes em seu dia-a-dia de notificações.

Com a evolução, a base própria tende a se tornar a primeira fonte de consulta do CSIRT, embora certamente não será a única visto que não há como ser exaustiva.

Dados para alimentar a base própria podem ser obtidos, por exemplo, a partir de:

• consulta a um CSIRT conhecido ou fórum de CSIRTs (ex: FIRST);
• resposta recebida à notificação enviada e que foi encaminhada ao contato/grupo responsável;
• notificação recebida anteriormente;
• networking em reuniões, conferências e treinamentos;
• filiação à instituições/grupos de combate a abusos (ex: APWG, M3AAWG, etc.).

Algumas considerações importantes sobre a base própria:

• incluir somente dados confiáveis, relevantes e previamente verificados;
• estabelecer uma rotina periódica para verificação que contemple:
  • adição de novos contatos;
  • atualização de contatos existentes, por exemplo, por mudança de funcionário no cargo ou comunicado de mudança de e-mail de um CSIRT/contato de abuso;
  • remoção de contatos desatualizados, por exemplo, contato pessoal que mudou de empregador, e-mail retornando erro, etc.

Alternativas para busca de contatos, caso as demais falharem, podem ser:

• Página Web da instituição;
• Perfil oficial da instituição em redes sociais (Ex: Twitter, Facebook, LinkedIn);
• Contato do provedor de conexão (upstream provider).

5. Formas e formato de notificar

Existem diferentes formas para se notificar incidentes, embora algumas sejam mais recomendadas que outras em determinadas situações:

• e-mail: método mais usual e eficaz de envio de notificações. É o mais recomendado para grupos de resposta a incidentes por sua facilidade de automatização, o que permite ganho de escala na submissão de grandes quantidades de incidentes. Demais opções devem ser usadas apenas quando o e-mail não tenha se mostrado efetivo ou não esteja disponível.
  Sobre a caixa postal de envio das notificações, recomenda-se que:
  • no caso de instituições/CSIRTs, utilize endereço de e-mail corporativo e com nome que permita identificação do grupo (ex: não usar contas como root@localhost, test);
  • a caixa não seja exclusiva para envio e que permita a interação entre as partes (ex: para esclarecer dúvidas, trocar informações, etc.);
  • que tenha um endereço "Reply-To" adequadamente configurado.
• formulário Web: método alternativo e mais indicado para notificações por usuários finais, por ser mais interativo;
  
  
• telefone: se utilizado como a forma principal de contato para notificações provavelmente será bastante custosa, tanto em termos financeiros como de eficiência do trabalho de tratamento de incidentes. É mais indicado como alternativa para situações complexas ou emergenciais. Ainda assim, recomenda-se o envio dos detalhes sobre o incidente por e-mail.
  
  Para instituições que possuem sistema autônomo (AS), recomenda-se o uso de telefones INOC. INOC-DBA é uma rede VoIP, exclusiva para comunicação entre ASes, na qual as chamadas são feitas usando o número do AS (ASN) seguido de um ramal. Permite estabelecer um canal direto de comunicação (hotline) entre NOCs e CSIRTs dos ASes participantes. No Brasil, adotou-se como padrão "ASN*800" para o telefone dos CSIRTs (ex: usa-se 22548*800 para falar com o CERT.br). Para mais detalhes, veja https://inoc.nic.br/

Quando os canais formais não resultarem em resposta, pode-se buscar métodos alternativos tais como:

• chat;
• redes sociais.

6. O que incluir na notificação

O conteúdo da notificação precisa ser claro, em formato simples e deve incluir as informações necessárias para a rápida e correta identificação do problema e da ação requerida.

É importante também que o campo referente ao "Assunto" (Subject) do e-mail contenha uma descrição clara e sucinta sobre o conteúdo da notificação.

Sobre o formato da notificação, recomenda-se:

• utilizar formato texto. Formatos como .pdf, .doc, .html .xls, .zip, .png, .jpg, .gif, entre outros, dificultam a leitura direta e também o processamento automatizado dos dados;
• incluir uma linha em branco entre os parágrafos para facilitar a leitura;
• evitar linhas longas. Recomenda-se entre 70 e 80 caracteres por linha;
• utilizar criptografia na mensagem se houver necessidade de encaminhar informações sigilosas/evidências (ex: arquivo com dados pessoais como números de contas, de cartões de créditos e senhas, obtidos por site de fraude).

Sobre o teor da notificação, são dados essenciais a serem incluídos:

• logs completos que evidenciem a atividade maliciosa (ex: logs de redes, de sistemas, de servidor Web, mensagem de e-mail, etc.);
• informação de data, horário e time zone dos logs ou da ocorrência da atividade sendo notificada;
• qualquer outra informação que tenha sido utilizada para identificar a atividade maliciosa.

É de extrema importância que o horário de servidores e equipamentos de redes estejam sincronizados com uma fonte confiável de tempo (ex: via protocolo NTP) para que não haja disparidades na correlação de eventos, logs e outros dados.

Ainda sobre o teor da notificação, recomenda-se:

• sanitizar dados sigilosos ou que não sejam essenciais à identificação do incidente tais como dados pessoais (PII), IPs/redes e nomes de máquinas do destino/alvo;
• evitar mensagem de caráter jurídico, acusatório ou retaliativo visto que afasta a possibilidade de ação colaborativa e diminui a chance de resposta.

Um modelo genérico de notificação pode ser:

• Saudação;
• Apresentação breve da entidade que está enviando a notificação;
• Descrição do problema, incluindo:
  • explicação concisa;
  • evidências da ocorrência (logs completos, incluindo data, hora e time zone);
• Informações complementares que possam trazer mais esclarecimentos sobre o problema;
• Descrição da ação esperada;
• Agradecimento;
• Assinatura sucinta.

A seção 8. Modelos de notificações traz sugestões de modelos para diversos tipos de notificações, tanto em língua portuguesa como inglesa.

Em caso de comunicação subsequente, relativa a uma notificação, recomenda-se:

• responder ao e-mail usando sempre a opção "Reply All"
• manter o histórico das mensagens trocadas
• não modificar o "Subject" da mensagem
• não remover identificador gerado por algum sistema de controle de chamados (ticket)

visando preservar o contexto e facilitar o trabalho de tratamento dos incidentes.

7. Exemplos de consultas WHOIS e RDAP

Nos exemplos a seguir serão empregados, sempre que possível, números e nomes especialmente reservados para fins de documentação conforme descrito nas RFCs 2606, 3849, 5398 e 5737.

Quando forem exibidos resultados de buscas referenciando entidades terceiras não fictícias, os dados serão sanitizados ou parcialmente omitidos.

7.1. Considerações no uso do WHOIS

Apesar de a maioria dos serviços WHOIS oferecerem interface Web para consulta, esta forma de pesquisa pode não ser a mais adequada quando se deseja automatizar a busca, por exemplo, através de scripts. Neste caso, o cliente via linha de comando pode ser mais vantajoso.

Em geral, sistemas baseados em UNIX, Linux e BSD já possuem o software cliente instalado por padrão, ao passo que sistemas Windows requerem instalação adicional, por exemplo, do software whois disponível no pacote Windows Sysinternals.

É importante observar que:

• serviço WHOIS padrão utiliza a porta TCP/43. A máquina que for realizar as consultas requer acesso de saída a qualquer endereço da Internet na porta TCP/43;
• a grande maioria dos serviços de WHOIS limita a quantidade de consultas em função da origem. Ao implantar mecanismos automatizados para múltiplas consultas, é recomendado considerar alternativas como:
  • identificar o RIR correto antes de fazer a consulta, por exemplo via estatísticas de alocação de IPs dos RIRs. Estatísticas de todos os RIRs, atualizadas diariamente, podem ser obtidas em: https://ftp.lacnic.net/pub/stats/
  • implementar distribuição temporal das consultas, respeitando os limites definidos nos termos de uso do serviço.
• não existe padrão para a estrutura dos dados e nem para interface de consulta das bases WHOIS. Deve-se ficar atento para mensagens exibidas em linhas de comentários ou em campos "remarks" pois costumam exibir informações pertinentes tais como:
  
  • parâmetros para uso da interface;
  • contato e forma de notificar abusos.

Devido à falta de padronização dos objetos/campos das bases WHOIS, é possível encontrar endereço de contato de abusos em objetos/campos diversos, tais como:

• abuse-c / e-mail
• Comment
• remarks
• % Abuse contact for
• OrgAbuseEmail
• abuse-mailbox
• irt / irt-nfy
• irt / abuse-mailbox

onde IRT significa "Incident Response Team".

7.2. Pesquisa por IP sem determinação do servidor WHOIS

Ao não determinar o servidor específico para a busca, o resultado retornado pode variar em função do software cliente utilizado. Há clientes que possuem mecanismos de busca recursiva, que usam parâmetros de arquivo de configuração e outros que possuem alguma "inteligência" para identificação do servidor adequado. Recomenda-se ter mais de um software cliente disponível caso algum deles não consiga efetivar a pesquisa de forma satisfatória.

$ whois 192.0.2.1

[...]

NetRange:       192.0.2.0 - 192.0.2.255
CIDR:           192.0.2.0/24
NetName:        TEST-NET-1
NetHandle:      NET-192-0-2-0-1
Parent:         NET192 (NET-192-0-0-0-0)
NetType:        IANA Special Use
OriginAS:
Organization:   Internet Assigned Numbers Authority (IANA)
RegDate:        2009-06-29
Updated:        2013-08-30
Comment:        Addresses starting with "192.0.2.", "198.51.100.", or
                "203.0.113 ." are reserved for use in documentation
                and sample configurations.  They should never be used
                in a live network configuration.  No one has
                permission to use these addresses on the Internet.
[...]

OrgAbuseHandle: IANA-IP-ARIN
OrgAbuseName:   ICANN
OrgAbusePhone:  +1-310-301-5820
OrgAbuseEmail:  abuse@iana.org
OrgAbuseRef:    https://rdap.arin.net/registry/entity/IANA-IP-ARIN

Neste caso, os campos iniciados com "OrgAbuse" identificam os dados de contato de abuso.

7.3. Pesquisa por IP selecionando o servidor WHOIS

Eventualmente, o software cliente pode não ser capaz de identificar o servidor WHOIS adequado para a consulta. Será então necessário tentar manualmente diferentes servidores. Alternativas para se iniciar a busca são:

• whois da IANA: em geral indicará o RIR para o qual o endereço foi alocado e o respectivo servidor whois;
• whois dos RIRs: pode-se tentar um a um até encontrar o correto, ou um proxy Joint Whois (LACNIC ou APNIC).

No exemplo abaixo, a pesquisa será direcionada ao servidor do APNIC usando-se a opção "-h" (host):

$ whois -h whois.apnic.net 2001:DB8::1
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '2001:db8::/32'

% Abuse contact for '2001:db8::/32' is 'helpdesk@apnic.net'

inet6num:       2001:db8::/32
netname:        IPV6-DOC-AP
descr:          IPv6 prefix for documentation purpose
country:        AU
org:            ORG-ARAD1-AP
admin-c:        HM20-AP
tech-c:         HM20-AP
status:         ALLOCATED PORTABLE
remarks:        This address range is to be used for documentation
remarks:        purpose only. For more information please see
remarks:        http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html
mnt-by:         APNIC-HM
mnt-lower:      APNIC-HM
mnt-routes:     APNIC-HM
mnt-irt:        IRT-APNIC-AP
last-modified:  2017-10-06T12:52:11Z
source:         APNIC

irt:            IRT-APNIC-AP
address:        Brisbane, Australia
e-mail:         helpdesk@apnic.net
abuse-mailbox:  helpdesk@apnic.net
admin-c:        HM20-AP
tech-c:         NO4-AP
auth:           # Filtered
remarks:        APNIC is a Regional Internet Registry.
remarks:        We do not operate the referring network and
remarks:        are unable to investigate complaints of network abuse.
remarks:        For information about IRT, see www.apnic.net/irt
remarks:        helpdesk@apnic.net was validated on 2020-02-03
mnt-by:         APNIC-HM
last-modified:  2020-02-03T02:04:33Z
source:         APNIC

[...]

O contato "abuse" neste caso é exibido em dois locais: em um comentário logo no início da resposta "% Abuse contact for '2001:db8::/32' is 'helpdesk@apnic.net'" e também no objeto "irt", campo "abuse-mailbox".

7.4. Pesquisa WHOIS por nome de domínio

$ whois nic.br

[...]

domain:      nic.br
owner:       Núcleo de Inf. e Coord. do Ponto BR - NIC.BR
ownerid:     05.506.560/0001-36
responsible: Demi Getschko
country:     BR
owner-c:     FAN
tech-c:      FAN
nserver:     a.dns.br
nsstat:      20200913 AA
nslastaa:    20200913
nserver:     b.dns.br
nsstat:      20200913 AA
nslastaa:    20200913
nserver:     c.dns.br
nsstat:      20200913 AA
nslastaa:    20200913
nserver:     d.dns.br
nsstat:      20200913 AA
nslastaa:    20200913
nserver:     e.dns.br
nsstat:      20200913 AA
nslastaa:    20200913
dsrecord:    47828 ECDSASHA256 B9BEC0EAC0F064929C8586DB185537787015EC3A48F0894BEA74DEEA452F3060
dsstatus:    20200913 DSOK
dslastok:    20200913
created:     19970711 #46903
changed:     20180327
status:      published

nic-hdl-br:  FAN
person:      Frederico Augusto de Carvalho Neves
e-mail:      fneves@registro.br
country:     BR
created:     19971217
changed:     20200702

Como para domínios não existe um identificador para contato de abuso ("abuse-c"), então utiliza-se o contato técnico ("tech-c"), FAN.

7.5. Mapeamento de IP para ASN e busca por ASN usando WHOIS

Pode ser que se queira saber se um IP faz parte de um AS (ex: para agrupar um conjunto de notificações por ASN). Entretanto, nem todos os serviços de WHOIS identificam se um determinado IP está associado a um AS. Uma alternativa é utilizar o serviço de WHOIS do Team Cymru, que além de fazer o mapeamento de IP para ASN, identifica o RIR e o "Country Code" do respectivo IP/AS.

$ whois -h whois.cymru.com " -v 2001:12ff:0:4::6"

AS     | IP                | BGP Prefix      | CC | Registry | Allocated  | AS Name
22548  | 2001:12ff:0:4::6  | 2001:12ff::/32  | BR | lacnic   | 2007-12-19 | Núcleo de Inf. e Coord. do Ponto BR - NIC., BR

Ao se obter o ASN e o respectivo RIR, pode-se fazer outra pesquisa WHOIS para se obter os contatos:

$ whois -h whois.lacnic.net AS22548

% Copyright (c) Nic.br
%  The use of the data below is only permitted as described in
%  full by the terms of use at https://registro.br/termo/en.html ,
%  being prohibited its distribution, commercialization or
%  reproduction, in particular, to use it for advertising or
%  any similar purpose.
%  2022-03-18T14:03:13-03:00 - IP: 2001:12ff:0:7001:0:0:0:68

aut-num:     AS22548
owner:       Núcleo de Inf. e Coord. do Ponto BR - NIC.BR
ownerid:     05.506.560/0001-36
responsible: Demi Getschko
country:     BR
owner-c:     FAN
routing-c:   FAN
abuse-c:     FAN
created:     20011016
changed:     20210915
inetnum:     200.160.0.0/20
inetnum:     2001:12ff::/32
as-in:       from AS2914 100 accept ANY
as-in:       from AS3549 100 accept ANY
as-in:       from AS6939 100 accept ANY
as-in:       from AS16735 100 accept ANY
as-out:      to AS2914 announce AS22548
as-out:      to AS3549 announce AS22548
as-out:      to AS6939 announce AS22548
as-out:      to AS16735 announce AS22548

nic-hdl-br:  FAN
person:      Frederico Augusto de Carvalho Neves
e-mail:      fneves@registro.br
country:     BR
created:     19971217
changed:     20200702

% Security and mail abuse issues should also be addressed to
% cert.br, http://www.cert.br/ , respectivelly to cert@cert.br
% and mail-abuse@cert.br
%
% whois.registro.br accepts only direct match queries. Types
% of queries are: domain (.br), registrant (tax ID), ticket,
% provider, CIDR block, IP and ASN.

Neste caso, o contato de abuso pode ser localizado através do identificador "abuse-c:" e nos comentários há indicação de contato adicional a ser incluído em cópia nas notificações.

7.6. Exemplos de indicação de contato de abuso em campos diversos do WHOIS

Os exemplos abaixo ilustram o uso de campos diversos para informar contatos de abuso e formas de notificação. As informações foram obtidas a partir de consultas WHOIS a redes efetivamente em uso, porém os dados organizacionais e pessoais foram sanitizados ou omitidos.

7.6.1. Campo "Comment"

------------------------------------------

Comment:        *** The IP addresses under this netblock are in use by
Comment:        EXAMPLE customers ***
Comment:
Comment:        Please direct all abuse and legal complaints regarding
Comment:        these addresses to the EXAMPLE Abuse desk
Comment:        (compliance@example.com). Complaints sent to
Comment:        any other POC will be ignored.

------------------------------------------

------------------------------------------

Comment:        To report suspected security issues specific to
Comment:        traffic emanating from EXAMPLE online services,
Comment:        including the distribution of malicious content or
Comment:        other illicit or illegal material through a EXAMPLE
Comment:        online service, please submit reports to:
Comment:        * https://cert.example.com
Comment:
Comment:        For SPAM and other abuse issues, such as EXAMPLE
Comment:        Accounts, please contact:
Comment:        * abuse@example.com
Comment:
Comment:        To report security vulnerabilities in EXAMPLE products
Comment:        and services, please contact:
Comment:        * secure@example.com

------------------------------------------

------------------------------------------

Comment:        The activity you have detected originates from a
Comment:        dynamic hosting environment.
Comment:        For fastest response, please submit abuse reports at
Comment:        http://example.com/.../EXEAbuse
[...]
Comment:        All reports MUST include:
Comment:        * src IP
Comment:        * dest IP (your IP)
Comment:        * dest port
Comment:        * Accurate date/timestamp and timezone of activity
Comment:        * Intensity/frequency (short log extracts)
Comment:        * Your contact details (phone and email) Without these
Comment:        we will be unable to identify the correct owner of the
Comment:        IP address at that point in time.

------------------------------------------

7.6.2. Campo "remarks" e "% Abuse contact for"

------------------------------------------

% Abuse contact for '109.xxx.yyy.0 - 109.xxx.yyy.255' is 'abuse@example.net'

[...]

remarks:        trouble:      +---------------------------------------------------
remarks:        trouble:      | Abuse and Spam issues:  abuse@example.net        |
remarks:        trouble:      | * IN CASE OF HACK ATTACKS ILLEGAL ACTIVITY,      |
remarks:        trouble:      | * VIOLATION, SCANS, PROBES, SPAM, ETC. *         |
remarks:        trouble:      | DNS issues:             hostmaster@example.net   |
remarks:        trouble:      +---------------------------------------------------
remarks:        24x7 @ +1234567890

------------------------------------------

------------------------------------------

remarks:     Federal Higher education
remarks:     Security issues should be adressed to Fulano de Tal,
remarks:     email: fulano@exemplo.br, phone: +1234567890

------------------------------------------

------------------------------------------

remarks:        Email address for spam or abuse complaints : abuse@example.com

------------------------------------------

------------------------------------------

remarks:        *************************************************
remarks:        * For spam/abuse/security issues please contact *
remarks:        *   abuse@example.com, not this address.        *
remarks:        *   The contents of your abuse email will be    *
remarks:        *   forwarded directly on to our client for     *
remarks:        *   handling.                                   *
remarks:        *************************************************

------------------------------------------

7.6.3. Objeto "irt"

irt:            IRT-EXAMPLE
[...]
abuse-mailbox:  cert@example.nl
signature:      PGPKEY-A1B2C3D4
encryption:     PGPKEY-A1B2C3D4
[...]
irt-nfy:        cert@example.nl

7.7. Considerações no uso do RDAP

Existem diferentes maneiras de consultar serviços RDAP e de processar as respostas. Entre elas:

• navegador com interpretador JSON (ex: Firefox, Chrome);
• ferramentas comuns de linha de comando (ex: wget, curl);
• clientes Web ou de linha de comando disponibilizados pelo próprio serviço RDAP, como apresentado na seção 4.1.2.

Apesar de alguns serviços RDAP oferecerem cliente Web com facilidades para busca e visualização para os usuários, o uso de ferramentas de linha de comando permite a automatização de rotinas para múltiplas consultas. Ferramentas de linhas de comando, como wget e curl, são comumente encontradas em sistemas baseados em UNIX, Linux e BSD, e estão disponíveis também para Windows e macOS.

Uma consulta RDAP é construída basicamente de três elementos:

<URL base>/<recurso>/<dado para consulta>

Sendo:

• URL base: URL do endereço do servidor RDAP, incluindo eventual path adicional se tiver;
• recurso: tipo do recurso que se quer consultar, conforme a RFC 9082 (ex: ip, autnum, domanin, nameserver, entity);
• dado para consulta: dado sobre o qual se quer obter informações, conforme o tipo de recurso.

Se um servidor RDAP tiver as informações solicitadas, ele responderá com HTTP 200 junto com os dados solicitados em formato JSON. Caso o servidor RDAP não tenha as informações, ele poderá responder com um redirecionamento (HTTP 3XX) para outro servidor, ou retornará HTTP 404 indicando que as informações da solicitação não foram encontradas. Se uma consulta não puder ser concluída por outros motivos (ex: consulta incorreta, método não implementado, falha do servidor, etc.), uma resposta de erro HTTP apropriada será fornecida (4XX, 5XX).

A estrutura de dados JSON da resposta segue as definições da RFC 9083. A classe de objetos "entity" reúne várias informações de registro e pode representar diferentes entidades (como organizações, indivíduos, etc.). Entidades ("entities") podem ter uma ou mais funções, identificadas através de "roles". De maneira geral, para se identificar os contatos para notificação de abuso, deve-se buscar pelas "entities" que tenham função ("roles") "abuse" ou, na ausência desta, a função "technical". As informações de contatos são representadas em "vcardArray", conforme o formato JCard (JSON vCard).

É importante ter em mente que, apesar de as respostas RDAP seguirem o formato JSON, o parsing dos dados pode não ser uniforme entre todos os registries e registrars em virtude de escolhas de implementação, de políticas ou do mapeamento de dados com relação à base WHOIS. E que apesar de o RDAP ter contribuído de maneira significativa para representação do contato de abuso com o uso de "roles", ainda é possível observar informações de contato e instruções sobre como notificar abuso distribuídas em outros objetos, especialmente em "remarks".

Convém ainda considerar que:

• recomenda-se utilizar sempre HTTPS (TCP/443) em todas as consultas;
• apesar das capacidades de bootstrapping e redirecionamento serem muito úteis para encaminhar as consultas aos servidores autoritativos dos recursos, os serviços RDAP geralmente implementam limites ao número de consultas (rate limit) por endereço de origem. Se for necessário utilizar mecanismos automatizados para um grande número de consultas, é recomendado considerar alternativas como:
  • implementar distribuição temporal das consultas, respeitando os limites definidos nos termos de uso do serviço;
  • identificar o servidor do RIR autoritativo antes de realizar consulta, ao invés de consultar um único servidor bootstrapping. A IANA provê informações quanto à designação de recursos em https://data.iana.org/rdap/.

7.8. Pesquisa por IP com uso de bootstrapping

Não é possível fazer uma consulta RDAP sem indicar algum servidor. Quando não se sabe qual é o servidor autoritativo, pode-se utilizar um servidor com recursos de bootstrapping e redirecionamento.

Neste exemplo utilizaremos o servidor bootstrap do ARIN, que é capaz de encaminhar requisições de consultas tanto para recursos numéricos como de nome.

$ curl -s -L https://rdap.arin.net/bootstrap/ip/192.0.2.1 | jq .

[...]
        {
          "handle": "IANA-IP-ARIN",
          "vcardArray": [
            "vcard",
            [
              [
                "version",
                {},
                "text",
                "4.0"
              ],
[...]
              [
                "fn",
                {},
                "text",
                "ICANN"
              ],
              [
                "org",
                {},
                "text",
                "ICANN"
              ],
              [
                "kind",
                {},
                "text",
                "group"
              ],
              [
                "email",
                {},
                "text",
                "abuse@iana.org"
              ],
[...]            ]
          ],
          "roles": [
            "abuse",
            "technical"
          ],
[...]

Ao listar as "entities" da resposta, é possível identificar um contato para notificar abuso, que na verdade tem a dupla função "roles": ["abuse", "technical"].

Para melhor visualizar o redirecionamento, pode-se utilizar a opção do curl de exibir apenas cabeçalhos (-I). No exemplo abaixo é possível ver que o servidor bootstrapping do ARIN faz um redirecionamento (código HTTP 302) para o servidor do registry autoritativo do recurso, que neste caso é o servidor do próprio ARIN (registry).

$ curl -I -L https://rdap.arin.net/bootstrap/ip/192.0.2.1

HTTP/1.1 302
[...]
Location: https://rdap.arin.net/registry/ip/192.0.2.1
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *
Content-Type: application/x-troff-man

HTTP/1.1 200
[...]
Content-Type: application/rdap+json
Transfer-Encoding: chunked
Access-Control-Allow-Origin: *

7.9. Pesquisa por IP selecionando o servidor RDAP autoritativo

Eventualmente, para se evitar sobrecarregar de requisições um único servidor bootstrap, pode-se fazer a pesquisa diretamente ao servidor autoritativo do recurso.

No exemplo abaixo, a pesquisa será direcionada ao servidor do APNIC:

$ curl -s https://rdap.apnic.net/ip/2001:DB8::1 | jq .

[...]
{
  "roles": [
    "abuse"
  ],

[...]

  "vcardArray": [
    "vcard",
    [
      [
        "version",
        {},
        "text",
        "4.0"
      ],
      [
        "fn",
        {},
        "text",
        "IRT-APNIC-AP"
      ],
      [
        "kind",
        {},
        "text",
        "group"
      ],

[...]

     [
        "email",
        {},
        "text",
        "helpdesk@apnic.net"
      ],
      [
        "email",
        {
          "pref": "1"
        },
        "text",
        "helpdesk@apnic.net"
      ]
    ]
  ],
  "objectClassName": "entity",
  "handle": "IRT-APNIC-AP"
}

7.10. Pesquisa RDAP por nome de domínio

$  curl -s https://rdap.registro.br/domain/nic.br | jq .

[...]

{
  "objectClassName": "entity",
  "handle": "FAN",
  "vcardArray": [
    "vcard",
    [
      [
        "version",
        {},
        "text",
        "4.0"
      ],
      [
        "kind",
        {},
        "text",
        "individual"
      ],
      [
        "fn",
        {},
        "text",
        "Frederico Augusto de Carvalho Neves"
      ],
      [
        "email",
        {},
        "text",
        "fneves@registro.br"
      ],
      [
        "lang",
        {},
        "language-tag",
        "pt"
      ],

[...]

    ]
  ],
  "roles": [
    "technical"
  ],

[...]

Como não existe contato com role "abuse", utilizar o e-mail do contato com role "technical".

7.11. Mapeamento de IP para ASN e busca RDAP por ASN

Como exemplificado na seção 7.5, saber se um IP faz parte de um AS pode ser útil para agrupar um conjunto de notificações para o mesmo contato de um ASN. Todavia, nem todos os registries identificam se um determinado IP está associado a um AS. Uma alternativa é utilizar o serviço de WHOIS do Team Cymru que além de fazer o mapeamento de IP para ASN, identifica o RIR e o "Country Code (CC)" do respectivo IP/AS. Saber o CC de um recurso pode ser útil também para se localizar o time de resposta a incidentes nacional, como last resort para uma notificação.

Utilizando o mesmo mapeamento da seção 7.5, de IP 2001:12ff:0:4::6 para o ASN 22548, uma consulta RDAP para o contato de "abuse" do ASN seria:

$ curl -s -L https://rdap.lacnic.net/rdap/autnum/22548| jq .

[...]

{
  "objectClassName": "entity",
  "handle": "FAN",
  "vcardArray": [
    "vcard",
    [
      [
        "version",
        {},
        "text",
        "4.0"
      ],

[...]

      [
        "email",
        {},
        "text",
        "fneves@registro.br"
      ],

[...]

  ],
  "roles": [
    "administrative",
    "abuse"
  ],
[...]

Convém destacar que no caso específico de recursos numéricos designados ao Brasil, o RDAP do Registro.br já faz o mapeamento do IP para o respectivo ASN através da extensão "nicbr_autnum", conforme mostrado abaixo:

$ curl -s https://rdap.registro.br/ip/2001:12ff:0:4::6 | jq .
{
  "objectClassName": "ip network",
  "handle": "2001:12ff::/32",
  "startAddress": "2001:12ff::",
  "endAddress": "2001:12ff:ffff:ffff:ffff:ffff:ffff:ffff",
  "ipVersion": "v6",
  "name": "106736",
  "type": "ASSIGNED",
  "country": "BR",
  "status": [
    "active"
  ],
  "nicbr_autnum": 22548,

[...]

7.12. Exemplos de contato de abuso em objetos remarks do RDAP

O RDAP contribuiu para uma certa uniformização na representação do contato de abuso com o uso de "vCard" e "roles". Todavia, ainda é possível encontrar informações de contato, e instruções sobre como notificar abuso, distribuídas em outros objetos, especialmente em "remarks".

Os exemplos abaixo foram obtidos a partir de consultas RDAP a redes efetivamente em uso, porém os dados organizacionais e pessoais foram sanitizados ou omitidos.

------------------------------------------

  "remarks": [
    {
      "title": "Registration Comments",
      "description": [
        "EXAMPLE Web Services Abuse - The activity you have detected originates from a dynamic hosting environment. For fastest response, please submit abuse reports to abuse@example.com",
        "All reports MUST include:",
        "* src IP",
        "* dest IP (your IP)",
        "* dest port",
        "* Accurate date/timestamp and timezone of activity",
        "* Intensity/frequency (short log extracts)",
        "* Your contact details (phone and email)",
        "Without these we will be unable to identify the correct owner of the IP address at that point in time."
      ]
    },

------------------------------------------


 "handle": "103.xxx.yyy.0 - 103.xxx.yyy.255",
  "entities": [
    {
      "roles": [
        "technical"
      ],
    [...]
      "remarks": [
        {
          "description": [
            "send spam and abuse report to abuse@example.com"
          ],
          "title": "remarks"
        }
      ],

[...]

{
  "roles": [
    "abuse"
  ],

[...]

  "remarks": [
    {
      "description": [
        "send spam and abuse report to abuse@example.com"
      ],
      "title": "remarks"
    }
  ],

[...]

  "vcardArray": [
    "vcard",
    [
      [
        "version",
        {},
        "text",
        "4.0"
      ],
      [
        "fn",
        {},
        "text",
        "IRT-IN-EXAMPLE"
      ],
      [
        "kind",
        {},
        "text",
        "group"
      ],

[...]
      [
        "email",
        {},
        "text",
        "contact@example.com"
      ],
      [
        "email",
        {
          "pref": "1"
        },
        "text",
        "abuse@example.com"
      ]
    ]
  ],
  "objectClassName": "entity",
  "handle": "IRT-IN-EXAMPLE"
}

------------------------------------------

  "remarks": [
    {
      "title": "Registration Comments",
      "description": [
        "All EXAMPLE abuse reporting can be done via https://www.example.com/abuse"
      ]
    }
  ],

------------------------------------------

  "remarks": [
    {
      "title": "Registration Comments",
      "description": [
        "** The IP addresses under this netblock are in use by EXAMPLE Cloud customers ** \r",
        "\r",
        "Direct all copyright and legal complaints to \r",
        "https://support.example.com/legal/go/report\r",
        "\r",
        "Direct all spam and abuse complaints to \r",
        "https://support.example.com/code/go/gce_abuse_report\r",
        "\r",
        "For fastest response, use the relevant forms above.\r",
        "\r",
        "Complaints can also be sent to the EXAMPLE Abuse desk \r",
        "(example-cloud-compliance@example.com) \r",
        "but may have longer turnaround times.\r",
        "\r",
        "Complaints sent to any other POC will be ignored."
      ]
    }
  ],

------------------------------------------

8. Modelos de notificações

Os modelos apresentados a seguir foram elaborados para cobrir situações típicas de incidentes de segurança vivenciadas por grupos de resposta a incidentes. Não se trata de uma coletânea completa, mas de um conjunto de exemplos que podem ser adaptados para o uso por qualquer entidade e para uma variedade de outros incidentes.

Nas seções a seguir há uma descrição detalhada de cada um dos modelos, bem como são listados os tipos de incidentes que se enquadram em cada modelo de notificação.

8.1. Modelos para download

Para facilitar a integração com sistemas de acompanhamento e notificação de incidentes, os modelos também estão disponíveis em arquivos .txt nos idiomas português (pt-br) e inglês (en-us). Estes modelos estão todos disponíveis para download, compactados em arquivos .zip, conforme o idioma:

• Modelos em Português: certbr-templates-pt-br.zip
• Modelos em Inglês: certbr-templates-en-us.zip

Para facilitar a utilização em diversos sistemas operacionais, foram incluídos nos .zips, arquivos .txt convertidos para suportar diferentes delimitadores de linha (LF para Unix e CRLF para Windows) e distintas codificações, Latin1 (ISO-8859-1), UTF-8, UTF-16LE e ASCII.

Ao descompactar o arquivo .zip, será obtida uma estrutura de diretórios semelhante à descrita abaixo:

   diretorio-base
      |_ idioma
         |_ sistema-operacional-1
            |_ codificacao-1
            ...
            |_ codificacao-n
         |_ sistema-operacional-2
            |_ codificacao-1
            ...
            |_ codificacao-n

sendo que as codificações disponíveis variam conforme o idioma e o sistema operacional.

Dentro de cada .zip há um arquivo chamado README (ASCII) com detalhes acerca de seu conteúdo.

8.2. Licença de uso dos modelos de notificações

Os modelos de notificações de incidentes são disponibilizados pelo CERT.br sob a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional (CC BY-NC-SA 4.0).

Você tem o direito de:

• Compartilhar - copiar e redistribuir o material em qualquer suporte ou formato
• Adaptar - remixar, transformar, e criar a partir do material

O licenciante não pode revogar estes direitos desde que você respeite os termos da licença.

De acordo com os termos seguintes:

• Atribuição - Você deve dar o crédito apropriado, prover um link para a licença e indicar se mudanças foram feitas. Você deve fazê-lo em qualquer circunstância razoável, mas de maneira alguma que sugira ao licenciante a apoiar você ou o seu uso.
• NãoComercial - Você não pode usar o material para fins comerciais (um uso comercial é um uso primeiramente dirigido à obtenção de uma vantagem comercial ou compensação monetária).
• CompartilhaIgual - Se você remixar, transformar, ou criar a partir do material, tem de distribuir as suas contribuições sob a mesma licença que o original.

Mais detalhes sobre esta licença de uso dos Modelos estão disponíveis em: https://creativecommons.org/licenses/by-nc-sa/4.0/deed.pt_BR

8.3. Descrição das variáveis de texto

As variáveis de texto (placeholders) são representações de informações necessárias nos modelos. Elas devem ser substituídas pelo seu conteúdo correspondente em cada notificação a ser enviada. Seguem as descrições para as variáveis de texto empregadas nos modelos:

Variável                            Descrição

<ATTACK_TYPE>                       Descrição do ataque sendo notificado.

<ORGANIZATION_DESCRIPTION>          Breve descritivo da instituição
                                    que está enviando a notificação.

<ORGANIZATION_NAME>                 Nome da instituição que está enviando a
                                    notificação.

<ARTIFACT_DESCRIPTION>              Descritivo do artefato malicioso que está
                                    se solicitando a remoção.

<DOMAIN_CONTACT>                    E-mail do responsável pelo domínio
                                    sendo notificado.

<DOMAIN>                            Nome do domínio notificado.

<HOSTNAME>                          Porção da URL que identifica o
                                    nome completo do host (hostname).
                                    Hostname sendo notificado.

<HOSTNAME_OFFICIAL>                 Hostname da instituição sendo
                                    referenciada na fraude.

<IP>                                Endereço IP sendo notificado.

<NATIONAL_CSIRT>                    E-mail de contato do CSIRT nacional
                                    responsável pelo IP / rede.

<NETWORK_CONTACT>                   E-mail do responsável pela rede
                                    sendo notificada.

<NOTE_GEO>                          Observação acerca de geolocalização
                                    em páginas de phishing.

<PORT>                              Porta de conexão/serviço sendo notificada.

<PORT_PHISHING>                     Porta utilizada na URL do phishing.

<PROTOCOL>                          Protocolo de comunicação observado em
                                    conexão maliciosa sendo notificada.

<REGISTRAR_CONTACT>                 E-mail de contato do Registrar
                                    (entidade de registro) responsável
                                    pelo registro do domínio.

<SERVICE_NAME>                      Nome do serviço explorado para
                                    realização de ataque.

<SIGNATURE>                         Assinatura de quem está enviando a
                                    notificação.

<TIMEZONE>                          Fuso horário dos registros dos
                                    logs. Pode ser expresso nos
                                    formatos [+-]hh:mm, [+-]hhmm, ou
                                    [+-]hh. UTC "+hhmm" indica que a
                                    data/hora foi expressa em um fuso
                                    horário que é "hh" horas e "mm"
                                    minutos à frente da hora UTC. UTC
                                    "-hhmm" indica que a data/hora foi
                                    expressa em um fuso horário que é
                                    "hh" horas e "mm" minutos atrás da
                                    hora UTC. Alternativamente pode
                                    ser expresso simplesmente com "Z",
                                    que significa que o horário está
                                    em UTC.

<URL_ARTIFACT>                      URL do artefato malicioso.

<URL_DEFACEMENT>		    URL que sofreu desfiguração.

<URL_OFFICIAL>                      URL do site oficial da instituição
                                    reclamante da fraude.

<URL_PHISHING>                      URL do phishing.

<URL_PII>                           URL onde estão sendo publicados
                                    dados sensíveis de identificação
                                    pessoal.

8.4. Desfiguração de página

Desfiguração de página - Português

Modelo de notificação para casos onde deseja-se informar uma instituição brasileira que seu site foi desfigurado e o conteúdo adulterado permanece acessível.

Arquivo do Modelo: defacement-pt-br.txt

Subject: Desfiguracao de pagina <HOSTNAME>.
To: <NETWORK_CONTACT>, <DOMAIN_CONTACT>
Cc: cert@cert.br

Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Informamos que o endereço abaixo teve sua página desfigurada e que o
conteúdo alterado permanece online:

	<URL_DEFACEMENT>

Pedimos sua colaboração na análise e solução deste incidente.
Recomendamos também que as vulnerabilidades que permitiram esse ataque
sejam identificadas e corrigidas.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

Desfiguração de página - Inglês

Modelo de notificação para casos onde deseja-se informar uma instituição estrangeira que seu site foi desfigurado e o conteúdo adulterado permanece acessível.

Arquivo do Modelo: defacement-en-us.txt

Subject: Website defacement <HOSTNAME>
To: <NETWORK_CONTACT>, <DOMAIN_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

We have noticed that the web page below has been defaced and the
modified page remains online:

	<URL_DEFACEMENT>

We kindly request you to look into the matter. We also recommend
finding and mitigating the vulnerabilities that let the attack
succeed.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

8.5. Domínios utilizados para fraudes

Domínios utilizados para fraudes - Português

Modelo de notificação e solicitação de verificação de domínios brasileiros usados para prática de fraudes contra instituições brasileiras e/ou seus usuários, como por exemplo, quando o nome do domínio é similar ao da instituição referenciada na fraude e está associado a conteúdo fraudulento.

Para domínios .br, os casos podem ser notificados diretamente ao Registro.br (hostmaster@registro.br), mantendo o CERT.br em cópia.

Para novos gTLDs (registrados a partir de 2012), deve-se localizar a instituição responsável e o contato adequado para abusos, conforme indicado na seção 4.3. Top-Level Domains (TLDs).

É importante salientar que as entidades registradoras de domínios (Registrars e Registries) só tem capacidade de sanção contra domínios que estejam desrespeitando cláusulas contratuais, ou por ordem judicial. Se o procedimento para verificação do domínio não constatar violação de contrato, será necessário que a entidade vítima da fraude mova ação judicial contra o dono do domínio fraudulento, a fim de obter ordem judicial para cancelamento do domínio. Este modelo NÃO contempla esta situação.

Arquivo do Modelo: domain-pt-br.txt

Subject: Dominio usado em fraudes (<DOMAIN>)
To: <REGISTRAR_CONTACT>
Cc: cert@cert.br

Cara Entidade Registradora de Domínios,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Identificamos o seguinte domínio sendo utilizado para prática de fraudes:

    <DOMAIN>

Este domínio se faz passar pelo domínio da <ORGANIZATION_NAME>, cujo
site oficial é:

   <URL_OFFICIAL>

e está associado à páginas fraudulentas, como as destacadas abaixo:

   <URL_PHISHING>

Gentilmente solicitamos que o domínio em questão seja verificado e, se
possível, sejam instaurados os procedimentos administrativos cabíveis.

Não hesite em nos contactar caso necessite de mais informações.

Agradecemos desde já,


Atenciosamente,
<SIGNATURE>

Domínios utilizados para fraudes - Inglês

Modelo de notificação e solicitação de verificação de domínios NÃO brasileiros usados para prática de fraudes contra instituições brasileiras e/ou seus usuários, como por exemplo, quando o nome do domínio é similar ao da instituição referenciada na fraude e está associado a conteúdo fraudulento.

Tais casos devem ser notificados diretamente à organização onde o domínio foi registrado (Registrar), mantendo em cópia o CERT.br e o CSIRT Nacional do país de registro.

É importante salientar que as entidades registradoras de domínios (Registrars e Registries) só tem capacidade de sanção contra domínios que estejam desrespeitando cláusulas contratuais, ou por ordem judicial. Se o procedimento para verificação do domínio não constatar violação de contrato, será necessário que a entidade vítima da fraude mova ação judicial contra o dono do domínio fraudulento, a fim de obter ordem judicial para cancelamento do domínio. Este modelo NÃO contempla esta situação.

Arquivo do Modelo: domain-en-us.txt

Subject: Domain used in frauds (<DOMAIN>)
To: <REGISTRAR_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br

Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the Registrar contact
for the domain mentioned below. This message is intended for the
person responsible for treating abuse cases and if this is not the
correct address, please forward this message to the appropriate party.

We have detected the following domain being used for fraud:

    <DOMAIN>

This is a domain pretending to be a <ORGANIZATION_NAME> domain,
whose official website is

    <URL_OFFICIAL>

and it is associated with fraudulent pages such as those listed
below:

    <URL_PHISHING>

We kindly ask your cooperation to verify this domain and, according to
your policies, take the appropriate measures to cease any
irregularity, if it's the case.

Please let us know if any additional information is required.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

8.6. Divulgação de dados pessoais sensíveis

Divulgação de dados pessoais sensíveis - Português

Modelo de notificação para casos onde dados pessoais sensíveis, indevidamente obtidos, estão sendo divulgados através de site em rede/domínio no Brasil.

Caso seja evidente que o domínio do site usado para a divulgação dos dados não é malicioso e/ou possa estar sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Arquivo do Modelo: pii-pt-br.txt

Subject: Dados pessois sensiveis divulgados em seu site <HOSTNAME>
To: <NETWORK_CONTACT>
Cc: cert@cert.br

Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Tomamos conhecimento que sua infraestrutura está sendo utilizada para
armazenar e divulgar dados sensíveis de identificação pessoal de
usuários de nossa instituição/cliente.

Estes dados estão acessíveis através do site:

   <URL_PII>

   <HOSTNAME> com endereço IP <IP>

Solicitamos sua colaboração para que:

  * sejam removidos todos os dados armazenados e páginas relacionadas;

  * nos sejam enviados quaisquer logs ou outras informações
    relacionadas à publicação destes dados, se possível, de acordo com
    suas políticas. Tais informações podem ser de grande valia em
    nossas análises.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

Divulgação de dados pessoais sensíveis - Inglês

Modelo de notificação para casos onde dados pessoais sensíveis, indevidamente obtidos, estão sendo divulgados através de site em rede/domínio no exterior.

Caso seja evidente que o domínio do site usado para a divulgação dos dados não é malicioso e/ou possa estar sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Arquivo do Modelo: pii-en-us.txt

Subject: Sensitive personal information published at your site <HOSTNAME>
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

We have noticed that your infrastructure is being used to store and
publish sensitive personally identifiable information (PII) from our
users/customers.

These data are accessible at:

    <URL_PII>

    <HOSTNAME> with IP <IP>

We kindly ask your cooperation:

  * to delete all stored data and related pages;

  * if possible, and according to your policies, to send us any logs
    or other information regarding the publication of to this data. It
    could help us in our analysis.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

8.7. Ataques à rede em geral

Ataques à rede em geral - Português

Modelo de notificação para casos de ataques de varredura de portas, de força bruta e tentativas de exploração de vulnerabilidades conhecidas, originados a partir de IPs em redes no Brasil.

Neste modelo, o <ATTACK_TYPE> deve ser substituído por um descritivo do tipo de ataque identificado nos logs que serão enviados na notificação. Alguns exemplos de <ATTACK_TYPE> são:

• ataque de varredura de portas;
• ataque de força bruta SSH (22/TCP);
• ataque de força bruta TELNET (23/TCP);
• tentativas de exploração de vulnerabilidades conhecidas em servidores Web.

Arquivo do Modelo: misc-pt-br.txt

Subject: <IP> - maquina realizando atividades maliciosas
To: <NETWORK_CONTACT>
Cc: cert@cert.br

Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Os logs anexados ao final desta mensagem mostram atividades maliciosas
aparentemente partindo de um endereço IP em sua rede. São amostras de
<ATTACK_TYPE>. Os horários estão em UTC<TIMEZONE>.

Pode tratar-se de:

  * uma máquina em sua rede que foi comprometida e está sendo usada
    como base para ataques, ou;

  * algum usuário legítimo envolvido em atividades que, provavelmente,
    são contrárias à sua política de uso aceitável da rede.

Em qualquer um dos casos pedimos sua colaboração na análise e solução
deste incidente.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

##################################################################
## LOGs em UTC<TIMEZONE>

Ataques à rede em geral - Inglês

Modelo de notificação para casos de ataques de varredura de portas, de força bruta e tentativas de exploração de vulnerabilidades conhecidas, originados a partir de IPs do exterior.

Neste modelo, o <ATTACK_TYPE> deve ser substituído por um descritivo do tipo de ataque identificado nos logs que serão enviados na notificação. Alguns exemplos de <ATTACK_TYPE> são:

• port scanning attack;
• SSH (22/TCP) brute force attack;
• TELNET (23/TCP) brute force attack;
• attempts to exploit known Web server vulnerabilities.

Arquivo do Modelo: misc-en-us.txt

Subject: <IP> - possible malicious activity from this host
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br

Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.


You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

The logs attached at the end of this message show malicious activity
originated from an IP address in your network. They are samples of
<ATTACK_TYPE>. All times are UTC<TIMEZONE>.

Either:

  * a machine in your network has been compromised and is now being
    used to launch attacks, or;

  * a legitimate user is engaged in activity that is probably in
    violation of your Terms of Service.

We kindly request you to look into the matter.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

##################################################################
## LOGs - all times are UTC<TIMEZONE>

8.8. Servidor DNS malicioso

DNS malicioso - Português

Modelo de notificação para casos de servidor DNS, ativo em IPs de redes no Brasil, respondendo maliciosamente, de forma autoritativa, para nomes de domínios de instituições conhecidas, a fim de direcionar os usuários para sites falsos (ataque de sequestro de DNS).

Arquivo do Modelo: rogue-dns-pt-br.txt

Subject: <IP> - Servidor DNS malicioso usado em sequestro de DNS
To: <NETWORK_CONTACT>
Cc: cert@cert.br

Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Nossos logs indicam que o seguinte IP da sua rede

    Endereço IP: <IP>

é um servidor DNS que permite abuso de duas formas:

  * atua como um servidor DNS malicioso, usado para ataques de
    sequestro de DNS, isto é, fornecendo respostas autoritativas (flag
    'aa' presente na saída do comando dig) maliciosas para domínios
    sobre os quais não tem autoridade;

  * atua como um servidor DNS recursivo aberto, que pode ser explorado
    para amplificação de tráfego em ataques DDoS.

Tal servidor DNS malicioso está fornecendo respostas incorretas para
nome(s) de domínio da nossa organização e/ou outros domínios
conhecidos (como bancos, serviços de pagamento, comércio eletrônico,
etc.), com o objetivo de redirecionar os usuários para sites falsos.

Pode tratar-se de:

  * um servidor DNS instalado pelo próprio atacante (por exemplo,
    contratando serviços de hospedagem ou de nuvem), ou;

  * um servidor DNS legítimo que foi comprometido.

Em qualquer um dos casos pedimos sua colaboração na análise e solução
deste incidente.

Ao final desta desta mensagem anexamos partes de nossos logs de
consultas DNS para facilitar sua análise. Todos os horários estão em
UTC<TIMEZONE>.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

##################################################################
## LOGs em UTC<TIMEZONE>

DNS malicioso - Inglês

Modelo de notificação para casos de servidor DNS, ativo em IPs de redes no exterior, respondendo maliciosamente, de forma autoritativa, para nomes de domínios de instituições conhecidas, a fim de direcionar os usuários para sites falsos (ataque de sequestro de DNS).

Arquivo do Modelo: rogue-dns-en-us.txt

Subject: <IP> - Rogue DNS server used in DNS Hijacking Attacks.
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br

Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

Our logs indicate that

	IP Address: <IP>

in your network is a malicious DNS server acting both

  * as a rogue DNS server used in DNS hijacking attacks, that is, it
    is providing malicious authoritative answers ('aa' flag present in
    a dig command output) for domains it does not have authority over;

  * as an open recursive DNS server, that can be exploited for traffic
    amplification in order to launch DDoS attacks.

Such rogue DNS server is providing wrong answers to domain name(s)
from our organization and/or other well-known domains (like banks,
payment services, e-commerce, etc.) with the purpose of redirecting
users to phishing sites.

Either:

  * this is a DNS server installed by the attacker (e.g. buying
    hosting or cloud services for this purpose);

  * this is a legitimate DNS server that has been compromised.

In either case, we kindly request you to look into the matter.

At the bottom of this message we have attached parts of our DNS query
logs in order to help you track down this activity. All times are
UTC<TIMEZONE>.

You can find a description of DNS hijacking and Rogue DNS servers at:

  https://en.wikipedia.org/wiki/DNS_hijacking

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

##################################################################
## LOGs - all times are UTC<TIMEZONE>

8.9. DDoS por botnet sem spoofing

DDoS por botnet sem spoofing - Português

Modelo de notificação para casos de ataque de negação de serviço a instituição brasileira, realizado por IPs de redes no Brasil, caracterizados por participarem de botnet, sem spoofing de endereço.

Arquivo do Modelo: dosbot-pt-br.txt

Subject: <IP> usado em ataque de negacao de servico.
To: <NETWORK_CONTACT>
Cc: cert@cert.br


Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Nossos logs indicam que um dispositivo da sua rede participou de um
ataque de negação de serviço contra nossa instituição/cliente. Ao
final desta mensagem anexamos partes dos logs para facilitar a
análise. Os horários estão em UTC<TIMEZONE>.

O tráfego analisado é compatível com atividade de botnet usada para
DDoS. Também em função dos padrões de tráfego, acreditamos que o
endereço IP de origem dos pacotes NÃO tenha sido adulterado.

Pode tratar-se de:

  * um computador/dispositivo de rede que foi comprometido e está
    sendo controlado remotamente ("bot") para realização de ataques,
    ou;

  * algum usuário legítimo envolvido em atividades que, provavelmente,
    são contrárias à sua política de uso aceitável da rede.

Em qualquer um dos casos pedimos sua colaboração na análise e solução
deste incidente.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

##################################################################
## LOGs em UTC<TIMEZONE>

DDoS por botnet sem spoofing - Inglês

Modelo de notificação para casos de ataque de negação de serviço a instituição brasileira, realizado por IPs de redes no exterior, caracterizados por participarem de botnet, sem spoofing de endereço.

Arquivo do Modelo: dosbot-en-us.txt

Subject: <IP> used in denial of service attack.
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

Our logs indicate that a computer/network device in your network
participated in a deny of service attack against our company /
customer. At the end of this message we have attached partial logs in
order to facilitate your analysis. All times are UTC<TIMEZONE>.

The network traffic shows specific characteristics related to DDoS
botnet activities. Still according to traffic patterns we do NOT
believe the source IP address has been spoofed.

Either:

  * a computer/network device has been compromised and is being
    remotely controlled (bot) to launch attacks, or;

  * a legitimate user is engaged in activity that is probably in
    violation of your Terms of Service.

In either case, we kindly request you to look into the matter.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

##################################################################
## LOGs - all times are UTC<TIMEZONE>

8.10. Ataque de negação de serviço distribuído com uso de amplificação (DRDoS)

Ataque de negação de serviço distribuído com uso de amplificação (DRDoS) - Português

Modelo de notificação para casos de ataque de negação de serviço distribuído com uso de amplificação (DRDoS) contra instituição brasileira, com IP de rede no Brasil participando como amplificador do ataque.

Nos casos de amplificação/reflexão, em virtude do uso de endereços de origem adulterados (spoofing), só é possível notificar os servidores de amplificação/reflexão e não os responsáveis pelas máquinas que originaram as requisições (origem do abuso).

Neste modelo, <SERVICE_NAME> deve ser substituído pelo descritivo do serviço/protocolo abusado para produzir a amplificação do ataque. Alguns exemplos de <SERVICE_NAME> são:

• CHARGEN (UDP/19) aberto para Internet;
• DNS (UDP/53) recursivo aberto;
• NTP (UDP/123) permitindo comando "monlist";
• SNMP (UDP/161) aberto para Internet;
• SSDP (UDP/1900) aberto para Internet.

Arquivo do Modelo: drdos-pt-br.txt

Subject: <IP> - servico abusado para ataque de negacao de servico.
To: <NETWORK_CONTACT>
Cc: cert@cert.br


Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Nossos logs indicam que uma máquina da sua rede participou de um
ataque de negação de serviço contra nossa instituição/cliente. Ao
final desta mensagem anexamos partes dos logs referentes ao ataque. Os
horários estão em UTC<TIMEZONE>.

A análise do tráfego indica que o serviço

  <SERVICE_NAME>

encontra-se possivelmente ativo em sua rede, no endereço

  IP: <IP>

e servindo como amplificador de tráfego em ataques de negação de
serviço.

Este serviço pode gerar respostas de tamanho muito grande (várias
vezes maior que o da requisição) e, através de requisições forjadas
com endereço IP adulterado (IP spoofing), um atacante pode direcionar
as respostas ao alvo de seu ataque. Tal abuso parece ocorrer porque o
serviço aparenta atender, sem restrições, a qualquer requisição
proveniente da Internet.

Solicitamos sua colaboração na solução deste incidente, seja
corrigindo o problema que permite o abuso do serviço ou desativando-o
completamente, caso não tenha uso efetivo.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

##################################################################
## LOGs em UTC<TIMEZONE>

Ataque de negação de serviço distribuído com uso de amplificação (DRDoS) - Inglês

Modelo de notificação para casos de ataque de negação de serviço distribuído com uso de amplificação (DRDoS) contra instituição brasileira, com IP de rede no exterior participando como amplificador do ataque.

Nos casos de amplificação/reflexão, em virtude do uso de endereços de origem adulterados (spoofing), só é possível notificar os servidores de amplificação/reflexão e não os responsáveis pelas máquinas que originaram as requisições (origem do abuso).

Neste modelo, <SERVICE_NAME> deve ser substituído pelo descritivo do serviço/protocolo abusado para produzir a amplificação do ataque. Alguns exemplos de <SERVICE_NAME> são:

• CHARGEN (UDP/19) open to Internet;
• DNS (UDP/53) open resolver;
• NTP (UDP/123) allowing "monlist";
• SNMP (UDP/161) open to Internet;
• SSDP (UDP/1900) open to Internet.

Arquivo do Modelo: drdos-en-us.txt

Subject: <IP> - service abused in denial of service attack.
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

Our logs indicate that a computer in your network participated in a
denial of service attack against our company/customer. At the end of
this message we have attached partial logs in order to facilitate your
analysis. All times are UTC<TIMEZONE>.

The network traffic indicates a service

  <SERVICE_NAME>

possibly active in your network at

   IP:  <IP>

and serving as amplifier in denial of service attacks.

This service can produce large responses (several times larger than
the request size) and an attacker can abuse it by creating spoofed
requests in a way that the responses are directed to its desired
target. Such abuse seems to be taking place because the service
apparently is answering to requests from the open Internet without
any restriction.

We kindly ask your cooperation to solve this incident by correcting
the misconfigurations that allow the service abuse, or by disabling
the service completely if it has no effective use.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

##################################################################
## LOGs - all times are UTC<TIMEZONE>

8.11. Hospedagem de artefatos maliciosos

Hospedagem de artefatos maliciosos - Português

Modelo de notificação para casos de artefatos maliciosos (ex: páginas com iFrame malicioso, código binário ou script, arquivo tipo .pac, etc) hospedados em IPs de redes no Brasil.

Neste modelo, <ARTIFACT_DESCRIPTION> deve ser substituído por um descritivo do artefato malicioso para o qual se pede a remoção, e de como foi detectado, a fim de permitir o entendimento do problema e das entradas de log anexas. Alguns exemplos de <ARTIFACT_DESCRIPTION> são:

• código malicioso utilizado em esquemas de phishing/scam para furto de identidade. As URLs foram obtidas de mensagens de e-mail que referenciavam nossa instituição ou destinadas à usuários da nossa rede;
• arquivo malicioso utilizado em tentativas de ataque a aplicações Web vulneráveis à inclusão de arquivo remoto (RFI - Remote File Inclusion). As URLs foram extraídas de logs de nossos servidores Web;
• arquivo de configuração automática de proxy (.pac) utilizado para direcionar os usuários a proxies maliciosos/páginas falsas, usados em esquemas de fraude para furto de identidade. As URLs foram extraídas de computadores comprometidos ou de amostras de código malicioso (trojan);
• código malicioso inserido como "iFrame" oculto em página Web, realizando ataques de falsificação de solicitação (Cross-Site Request Forgery - CSFR), com propósito de adulterar configurações de modem (CPE) ou roteador Wi-Fi e então redirecionar usuários a sites fraudulentos.

Caso seja evidente que o domínio usado na URL do artefato não é malicioso e que esteja sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Arquivo do Modelo: malware-pt-br.txt

Subject: Artefato malicioso hospedado em <HOSTNAME> -> <IP>.
To: <NETWORK_CONTACT>
Cc: cert@cert.br


Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Nossos logs indicam que seu site está hospedando artefato
malicioso. Trata-se de <ARTIFACT_DESCRIPTION>.

O artefato está hospedado em:

   <URL_ARTIFACT>

   <HOSTNAME> com endereço IP  <IP>

Ao final desta desta mensagem anexamos partes de nossos logs para
facilitar a análise. Os horários estão em UTC<TIMEZONE>.

Solicitamos sua colaboração para que:

  * o código malicioso seja removido do site;

  * seja verificado se esta máquina foi comprometida e, possivelmente,
    esteja sendo usada por invasores como repositório de ferramentas,
    ou se um usuário legítimo está envolvido em atividades que são,
    provavelmente, contrárias à sua política de uso aceitável da rede.

Caso haja mais de um código malicioso hospedado em sua rede, você
receberá múltiplas mensagens semelhantes a esta, cada uma contendo
evidências (logs) diferentes.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>


##################################################################
## LOGs em UTC<TIMEZONE>

Hospedagem de artefatos maliciosos - Inglês

Modelo de notificação para casos de artefatos maliciosos (ex: páginas com iFrame malicioso, código binário ou script, arquivo tipo .pac, etc) hospedados em IPs de redes no exterior.

Neste modelo, <ARTIFACT_DESCRIPTION> deve ser substituído por um descritivo do artefato malicioso para o qual se pede a remoção, e de como foi detectado, a fim de permitir o entendimento do problema e das entradas de log anexas. Alguns exemplos de <ARTIFACT_DESCRIPTION> são:

• malware used in phishing/scam schemes for identity theft. The URLs were obtained from e-mail messages impersonating our organization or sent to users in our network;
• malicious file used in attack attempts against Web applications vulnerable to Remote File Inclusion (RFI). The URLs were obtained from our Web servers logs;
• proxy Auto-Configuration file (.pac) used to refer users to malicious proxy/page used in identity theft fraud. The URLs were obtained from compromised computers or malware samples;
• malicious code inserted as hidden iFrame into Web page, performing Cross-Site Request Forgery (CSFR) attack with the purpose of changing modem (CPE) or Wi-Fi router settings and then redirect users to fraudulent sites.

Caso seja evidente que o domínio usado na URL do artefato não é malicioso e que esteja sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Arquivo do Modelo: malware-en-us.txt

Subject: Malicious artifact hosted at your site (<HOSTNAME> -> <IP>)
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

Our logs indicate that your site is hosting malicious artifact. It
seems to be a <ARTIFACT_DESCRIPTION>.

The artifact is hosted at:

   <URL_ARTIFACT>

   <HOSTNAME> with IP address <IP>

At the end of this message we have attached partial logs in order to
facilitate your analysis. All times are UTC<TIMEZONE>.

We kindly ask your cooperation to:

  * remove the malicious files from your site;

  * verify whether this machine has been compromised and it's being
    used by intruders to host malicious files, or a legitimate user is
    engaged in activity that is probably in violation of your Terms of
    Service.

In case we detect more than one malicious code hosted on your network,
you will receive multiple messages similar to this, each one containing
different evidence (logs).

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>


##################################################################
## LOGs - all times are UTC<TIMEZONE>

8.12. Phishing simples ou com geolocalização

Phishing simples ou com geolocalização - Português

Modelo de notificação para de casos de páginas falsas (phishing) hospedadas em IPs e/ou domínio brasileiros, referenciando instituições brasileiras ou estrangeiras.

Caso seja evidente que o domínio usado na URL do phishing <URL-PHISHING> não é malicioso e que esteja sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Em casos de páginas de phishing que utilizam técnicas de geolocalização para serem exibidas apenas a IPs alocados ao Brasil, acrescentar a mensagem abaixo em substituição ao item <NOTE_GEO>. Do contrário, apenas remover <NOTE_GEO> do texto principal.

IMPORTANTE: Esta página falsa faz uso de técnicas de geolocalização e
            somente pode ser visualizada por IPs alocados ao Brasil.
            Assim, caso a página não esteja visível em seu navegador,
            por favor procure por ela diretamente no sistema de
            arquivos do servidor Web.

Arquivo do Modelo: phishing-pt-br.txt

Subject: Pagina falsa hospedada em (<HOSTNAME> -> <IP>)
To: <NETWORK_CONTACT>
Cc: cert@cert.br

Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Identificamos um site de phishing hospedado em:

   <URL_PHISHING>

   <HOSTNAME> com endereço IP <IP>

Esta página falsa se faz passar pela página da <ORGANIZATION_NAME> com
o propósito de cometer fraude contra a instituição e/ou seus usuários.
O site legítimo da instituição é:

   <URL_OFFICIAL>

<NOTE_GEO>

Solicitamos sua colaboração, de acordo com suas políticas, para que:

  * seja interrompido o acesso a esta página falsa;

  * nos sejam enviados quaisquer logs ou outras informações
    relacionadas com o acesso a estes dados;

  * nos sejam enviados os arquivos que compõem o site de phishing;

  * seja determinado para onde os dados coletados estão sendo
    enviados, caso seja possível. Tais informações podem ser de grande
    valia em nossas análises.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

Phishing simples ou com geolocalização - Inglês

Modelo de notificação para de casos de página falsa (phishing) hospedadas em IPs e/ou domínios no exterior, referenciando instituições brasileiras.

Caso seja evidente que o domínio usado na URL do phishing <URL-PHISHING> não é malicioso e que esteja sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Em casos de páginas de phishing que utilizam técnicas de geolocalização para serem exibidas apenas a IPs alocados ao Brasil, acrescentar a mensagem abaixo em substituição ao item <NOTE_GEO>. Do contrário, apenas remover <NOTE_GEO> do texto principal.

IMPORTANT: This fake page makes use of geolocation techniques and can
           only be seen by IPs allocated to Brazil. Therefore, if the
           page is not visible on your Web browser, please, search for
           it directly at your Web server file system.

Arquivo do Modelo: phishing-en-us.txt

Subject: Phishing hosted at your site (<HOSTNAME> -> <IP>)
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

We detected a phishing web site hosted at:

    <URL_PHISHING>

    <HOSTNAME> with IP <IP>

This is a fake website pretending to be <ORGANIZATION_NAME> website
with the intent of committing fraud against the organization and/or
its users. The organization's legitimate website is:

    <URL_OFFICIAL>

<NOTE_GEO>

We kindly ask your cooperation, according to your policies:

  * to cease this activity and shut down the phishing page;

  * to send us any logs or other information regarding the access to
    this homepage;

  * to send us the phishing website files;

  * also, if in the course of your analysis you can determine where
    the collected data is being sent to, please send us this
    information. It could help us in our analysis.


Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

8.13. Phishing para dispositivos móveis

Phishing para dispositivos móveis - Português

Modelo de notificação para de casos de páginas falsas (phishing), direcionadas a usuários de dispositivos móveis, hospedadas em IPs e/ou domínio brasileiros, referenciando instituições brasileiras ou estrangeiras.

Para visualizar a página falsa a partir de um computador é necessário simular um dispositivo móvel, ajustando características como user agent e tamanho da janela de visualização.

Caso seja evidente que o domínio usado na URL do phishing <URL-PHISHING> não é malicioso e que esteja sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Arquivo do Modelo: phishing-mobile-pt-br.txt

Subject:  Pagina falsa para dispositivos moveis hospedada em <HOSTNAME> -> <IP>
To: <NETWORK_CONTACT>
Cc: cert@cert.br

Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Identificamos uma página falsa direcionada para dispositivos móveis
hospedada em:

   <URL_PHISHING>

   <HOSTNAME> com endereço IP <IP>

Esta página falsa se faz passar pela página da <ORGANIZATION_NAME> com
o propósito de cometer fraude contra a instituição e/ou seus usuários.
O site legítimo da instituição é:

   <URL_OFFICIAL>

Para visualizar a página falsa no navegador de um computador é
necessário simular um dispositivo móvel, em especial o user agent e o
tamanho da janela de visualização. Uma forma de fazê-lo é usando o
modo de design responsivo nativamente disponível em navegadores como
Chrome ou Firefox. Informações adicionais estão disponíveis em

Chrome:
https://developers.google.com/web/tools/chrome-devtools/device-mode?hl=pt-br

Firefox:
https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_Mode

Solicitamos sua colaboração, de acordo com suas políticas, para que:

  * seja interrompido o acesso a esta página falsa;

  * nos sejam enviados quaisquer logs ou outras informações
    relacionadas com o acesso a estes dados;

  * nos sejam enviados os arquivos que compõem o site de phishing;

  * seja determinado para onde os dados coletados estão sendo
    enviados, caso seja possível. Tais informações podem ser de grande
    valia em nossas análises.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

Phishing para dispositivos móveis - Inglês

Modelo de notificação para de casos de páginas falsas (phishing), direcionadas a usuários de dispositivos móveis, hospedadas em IPs e/ou domínios no exterior, referenciando instituições brasileiras ou estrangeiras.

Para visualizar a página falsa a partir de um computador é necessário simular um dispositivo móvel, ajustando características como user agent e tamanho da janela de visualização.

Caso seja evidente que o domínio usado na URL do phishing <URL-PHISHING> não é malicioso e que esteja sendo vítima de abuso, recomenda-se incluir o contato do respectivo domínio aos destinatários (To:) da notificação.

Arquivo do Modelo: phishing-mobile-en-us.txt

Subject: Phishing targeting mobile devices hosted at <HOSTNAME> -> <IP>
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br

Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

We detected a phishing page tailored for mobile devices hosted at:

    <URL_PHISHING>

    <HOSTNAME> with IP <IP>

This is a fake page pretending to be <ORGANIZATION_NAME> website
with the intent of committing fraud against the organization and/or
its users. The organization's legitimate website is:

    <URL_OFFICIAL>

To be able to see the fake page on a desktop browser it is necessary
to simulate the properties of a mobile device, especially the user
agent and viewport size. A way of doing this is using the responsive
design mode natively available in browsers like Chrome or Firefox.
Additional information is available at

Chrome:
https://developers.google.com/web/tools/chrome-devtools/device-mode

Firefox:
https://developer.mozilla.org/en-US/docs/Tools/Responsive_Design_Mode

We kindly ask your cooperation, according to your policies:

  * to cease this activity and shut down the phishing page;

  * to send us any logs or other information regarding the access to
    this homepage;

  * to send us the phishing website files;

  * also, if in the course of your analysis you can determine where
    the collected data is being sent to, please send us this
    information. It could help us in our analysis.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

8.14. Phishing com Pharming

Phishing com Pharming - Português

Modelo de notificação para de casos de páginas falsas (phishing) referenciando instituições brasileiras, hospedadas em IPs no Brasil, e em associação com ataques de pharming para direcionar os usuários.

Arquivo do Modelo: phishing-pharming-pt-br.txt

Subject: Pagina falsa da <ORGANIZATION_NAME> hospedada em <IP>
To: <NETWORK_CONTACT>
Cc: cert@cert.br

Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Identificamos uma página falsa hospedada em:

  Endereço IP:  <IP>

Esta página falsa se faz passar pela página da <ORGANIZATION_NAME>
com o propósito de cometer fraude contra a instituição e/ou seus
usuários. O site legítimo da instituição é:

  <URL_OFFICIAL>

Esta fraude também emprega alguns subterfúgios para alterar a
resolução de nomes no contexto do usuário a fim de direcioná-lo à
pagina falsa (ataque de pharming). Por esta razão, nem sempre é
possível a visualização da página falsa usando o navegador de
computadores não afetados.

As seguintes alternativas podem ser usadas para permitir a visualização
da página falsa:

1. via o comando "curl":

   curl -s -H "Host: <HOSTNAME_OFFICIAL>" <URL_PHISHING>

   Versões do curl estão disponíveis em:

     https://curl.se/download.html

   e também via os repositórios oficiais das distribuições de diversos
   sistemas operacionais.

2. editando o arquivo "hosts" da máquina e adicionando a seguinte linha:

   <IP>         <HOSTNAME_OFFICIAL>

   e acessando o site como:

   <URL_OFFICIAL>

   Por favor não se esqueça de remover a linha adicionada ao arquivo
   "hosts" após verificar o site de phishing.

3. mudando a configuração de proxy do browser:

   Configure o proxy do browser para:

     servidor:  <IP>
     porta:     <PORT_PHISHING>

   e acesse o site usando:

      <URL_OFFICIAL>

   Por favor, não se esqueça de remover esta configuração do proxy após
   verificar a página de phishing.

Solicitamos sua colaboração, de acordo com suas políticas, para que:

  * seja interrompido o acesso a esta página falsa;

  * nos sejam enviados quaisquer logs ou outras informações
    relacionadas com o acesso a estes dados;

  * nos sejam enviados os arquivos que compõem o site de phishing;

  * seja determinado para onde os dados coletados estão sendo
    enviados, caso seja possível. Tais informações podem ser de grande
    valia em nossas análises.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

Phishing com Pharming - Inglês

Modelo de notificação para de casos de páginas falsas (phishing) referenciando instituições brasileiras, hospedadas em IPs no exterior, e em associação com ataques de pharming para direcionar os usuários.

Arquivo do Modelo: phishing-pharming-en-us.txt

Subject: Fake page of <ORGANIZATION_NAME> hosted at <IP>
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

We detected a phishing web site hosted at

   IP address: <IP>

This is a fake website pretending to be <ORGANIZATION_NAME> website
with the intent of committing fraud against the organization and/or
its users. The organization's legitimate website is:

   <URL_OFFICIAL>

This fraud also uses some subterfuges to modify the name resolution to
misdirect users to the fake page (pharming attack). Because of this,
it's not always possible to see the page in the browser of unaffected
computers.

In order to access the page, the following options may be used:

1. using the "curl" command:

     curl -s -H "Host: <HOSTNAME_OFFICIAL>" <URL_PHISHING>

   curl versions are available at:

     https://curl.se/download.html

   and also via official repository of several operating system
   distributions.

2. editing the "hosts" file adding the follow line:

   <IP>          <HOSTNAME_OFFICIAL>

   and accessing the site as:

   <URL_OFFICIAL>

   Please, don't forget to remove the line added to the "hosts" file
   after checking the phishing site.

3. changing your browser proxy configuration:

    Set your proxy configuration to:

      server:  <IP>
      port:    <PORT_PHISHING>

    and access the site as:

      <URL_OFFICIAL>

   Please, don't forget to remove the browser proxy configuration
   after checking the phishing site.

We kindly ask your cooperation, according to your policies:

  * to cease this activity and shut down the phishing page;

  * to send us any logs or other information regarding the access to
    this homepage;

  * to send us the phishing website files;

  * also, if in the course of your analysis you can determine where
    the collected data is being sent to, please send us this
    information. It could help us in our analysis.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

8.15. Servidor enviando phishing scam

Servidor enviando phishing scam - Português

Modelo de notificação para casos de servidor de e-mail enviando phishing scam, a partir de IPs no Brasil.

Se após análise do cabeçalho da mensagem ficar evidente a conta de e-mail utilizada para envio, pode-se acrescentá-la às informações da notificação, pois pode ajudar a identificar uma conta de usuário ou máquina comprometida.

Entretanto, é importante salientar que identificar a conta do remetente apenas pelo campo "From:" da mensagem não é evidência suficiente, pois tal campo pode ser facilmente forjado, a menos que seja possível validá-lo, por exemplo, pela verificação de assinatura DKIM.

Arquivo do Modelo: phishing-scam-pt-br.txt

Subject:  <HOSTNAME> -> <IP> enviando e-mail phishing.
To: <NETWORK_CONTACT>
Cc: cert@cert.br


Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Usuários de nossa rede receberam mensagens de phishing enviadas a
partir do seguinte servidor de e-mail sob sua responsabilidade:

   Endereço: <IP>

   Servidor: <HOSTNAME>

A mensagem falsa tenta fazer o leitor acreditar que foi enviada
pelo(a) <ORGANIZATION_NAME> e tem o propósito de cometer fraude contra
a instituição e/ou seus usuários.

Ao final desta mensagem anexamos o e-mail original, incluindo
cabeçalhos, para sua análise.

Pode tratar-se de:

  * uma conta de usuário comprometida (senha conhecida pelo atacante)
    sendo abusada para envio de phishing;

  * um servidor de e-mail configurado como "open relay", permitindo
    envio de mensagens por terceiros, externos à sua rede;

  * um servidor ou dispositivo de usuário infectado com malware para
    envio de phishing;

  * algum sistema Web, com capacidade de envio de e-mail (ex:
    formulário em página Web), sendo abusado;

  * algum usuário legítimo envolvido em atividades que, provavelmente,
    são contrárias à sua política de uso aceitável da rede.

Em qualquer um dos casos pedimos sua colaboração na análise e solução
deste incidente.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>

##################################################################
## MENSAGEM com CABEÇALHOS

Servidor enviando phishing scam - Inglês

Modelo de notificação para casos de servidor de e-mail enviando phishing scam, a partir de IPs no exterior.

Se após análise do cabeçalho da mensagem ficar evidente a conta de e-mail utilizada para envio, pode-se acrescentá-la às informações da notificação, pois pode ajudar a identificar uma conta de usuário ou máquina comprometida.

Entretanto, é importante salientar que identificar a conta do remetente apenas pelo campo "From:" da mensagem não é evidência suficiente, pois tal campo pode ser facilmente forjado, a menos que seja possível validá-lo, por exemplo, pela verificação de assinatura DKIM.

Arquivo do Modelo: phishing-scam-en-us.txt

Subject: <HOSTNAME> -> <IP> sending phishing scam.
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

Users of our network have received phishing messages sent from the
following e-mail server:

   IP:     <IP>

   Server: <HOSTNAME>

The fake message tries to make the reader believe that it was sent by
<ORGANIZATION_NAME> for the purpose of committing fraud against the
institution and/or its users.

At the end of this message we have attached the original e-mail
including headers to facilitate your analysis.

Possible causes are:

  * a compromised user account (password known by the attacker) being
    abused to send phishing;

  * an e-mail server configured as an "open relay", allowing third
    parties external to your network to send messages;

  * a server or user device infected with malware to send phishing;

  * a Web system with e-mail sending capability (e.g. form on Web
    page), being abused;

  * a legitimate user is engaged in activity that is probably in
    violation of your Terms of Service.

In any case, we kindly request you to look into the matter.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>

##################################################################
## MESSAGE with HEADERS

8.16. Servidor de comando e controle de RAT

Servidor de comando e controle de RAT - Português

Modelo de notificação para casos de servidor de comando e controle de trojan de acesso remoto (RAT), ativo em IPs de redes no Brasil.

Se, após análise dos logs, estiver disponível a informação do nome do servidor (HOSTNAME), pode-se acrescentá-la ao conjunto de dados da notificação.

Arquivo do Modelo: cc-rat-pt-br.txt

Subject: Comando e Controle de RAT em <IP>.
To: <NETWORK_CONTACT>
Cc: cert@cert.br


Caro responsável,

Somos o grupo de tratamento de incidentes de segurança da
<ORGANIZATION_NAME>. A <ORGANIZATION_NAME> é <ORGANIZATION_DESCRIPTION>.

Você recebeu esta mensagem porque é o contato da rede citada abaixo no
WHOIS/RDAP. Esta mensagem é destinada ao responsável pela segurança de
sua rede e, se este não for o endereço correto, por favor encaminhe-a
ao destinatário apropriado.

Nossas análises indicam um servidor de comando e controle (C&C) de
trojan de acesso remoto (RAT) ativo em sua rede:

    Endereço IP:        <IP>

    Porta/Protocolo:    <PORT>/<PROTOCOL>

Servidores de comando e controle (C&C) são ferramentas utilizadas por
criminosos para controlar remotamente dispositivos infectados com
trojan de acesso remoto (RAT), normalmente com propósito de coletar
informações sensíveis, de maneira interativa (ex: durante atividade do
usuário em sessão de Internet Banking).

IMPORTANTE: a tentativa simples de conexão ao IP e porta acima citados
pode não resultar em qualquer mensagem pois tais servidores são, em
geral, programados para responder somente a comandos específicos e
parâmetros pré-determinados.

Ao final desta mensagem anexamos partes de nossos logs para facilitar
a análise. Trata-se de tráfego de rede capturado durante interações
entre o C&C e a máquina controlada. Os horários estão em UTC<TIMEZONE>.

Pode tratar-se de:

   * uma máquina em sua rede que foi comprometida e está sendo abusada
     por invasores, ou;

   * algum usuário legítimo envolvido em atividades que, provavelmente,
     são contrárias à sua política de uso aceitável da rede.

Em qualquer um dos casos pedimos sua colaboração para:

   * análise e solução deste incidente, a fim de cessar as atividades
     maliciosas deste servidor;

   * se possível, de acordo com suas políticas, nos enviar quaisquer
     logs ou outras informações armazenadas no servidor, relacionadas
     à nossa instituição. Tais informações podem ser de grande valia
     em nossas análises.

Agradecemos desde já e solicitamos que, se possível, uma resposta nos
seja enviada confirmando o recebimento desta mensagem.


Atenciosamente,
<SIGNATURE>


##################################################################
## LOGs em UTC<TIMEZONE>

Servidor de comando e controle de RAT - Inglês

Modelo de notificação para casos de servidor de comando e controle de trojan de acesso remoto (RAT), ativo em IPs de redes no exterior.

Se, após análise dos logs, estiver disponível a informação do nome do servidor (HOSTNAME), pode-se acrescentá-la ao conjunto de dados da notificação.

Arquivo do Modelo: cc-rat-en-us.txt

Subject: RAT command and control server active on <IP>
To: <NETWORK_CONTACT>
Cc: <NATIONAL_CSIRT>, cert@cert.br


Dear Sir/Madam,

We are the computer security incident response team for
<ORGANIZATION_NAME>. <ORGANIZATION_NAME> is <ORGANIZATION_DESCRIPTION>.

You have received this message because you are the WHOIS/RDAP contact
for the network mentioned below. This message is intended for the person
responsible for computer security at your site. If this is not the
correct address, please forward this message to the appropriate party.

Our logs indicate a remote access Trojan (RAT) command and control
(C&C) server active on your network:

    IP Address:		<IP>

    Port/Protocol:	<PORT>/<PROTOCOL>

Command and control servers (C&C) are tools used by criminals to
remotely control devices infected with RATs, in order to interactively
collect sensitive information (e.g. during user activity on Internet
Banking).

IMPORTANT: a simple attempt to connect to the aforementioned IP and
port may not result in any message because these servers are generally
programmed to respond only to specific commands and predetermined
parameters.

At the end of this message we have attached partial logs in order to
facilitate your analysis. This is network traffic captured during
interactions between the C&C and controlled machine. All times are
UTC<TIMEZONE>.

Either:

  * a machine in your network has been compromised and is being abused
    by intruders, or;

  * a legitimate user is engaged in activity that is probably in
    violation of your Terms of Service.

In either case, we kindly ask your cooperation, according to your
policies:

  * to solve this incident in order to cease the malicious activities
    from this server, and;

  * to send us any logs or information stored in this server related
    to our institution. Such information may be of great value in our
    analysis.

Thanks in advance. We would also appreciate a reply that this message
has been received.


Best regards,
<SIGNATURE>


##################################################################
## LOGs - all times are UTC<TIMEZONE>

9. Acrônimos

AS

Autonomous System ou sistema autônomo, é o conjunto de redes com a mesma política de roteamento.

ASN

Autonomous System Number é o identificador único para um AS.

ccTLD

veja TLD.

CSIRT

Computer Security Incident Response Team - Grupo de Resposta a Incidentes de Segurança em Computadores.

DNR

Domain Name Registry - Entidade que realiza o registro de nomes de domínio.

gTLD

veja TLD.

INOC-DBA

Inter-Network Operation Center Dial By Autonomous System Number.

jCard

JSON Format for vCard - Representação de dados vCard em formtato JSON.

JSON

JavaScript Object Notation - Notação de Objetos JavaScript.

NOC

Network Operations Center - Centro de operações de rede.

PII

Personally Identifiable Information - Informação de Identificação Pessoal ou, simplesmente, dado pessoal, é qualquer informação que sozinha ou agregada possa ser usada para identificar, contatar ou localizar uma pessoa.

RDAP

Registration Data Access Protocol - Protocolo de Acesso a Dados de Registro.

RIR

Regional Internet Registry - Entidade regional de registro de recursos Internet.

TLD

Top-Level Domain - É o nível mais alto da hierarquia de nomes de domínios da Internet (root domain). Existem diferentes tipos de TLDs, tais como Country-Code Top-Level Domains (ccTLD) para países, Generic Top-Level Domains (gTLD) para nomes genéricos, entre outros.

VoIP

Voice over Internet Protocol - Voz sobre IP ou telefonia IP.

10. Referências

Segue abaixo uma lista de referências que subsidiaram a escrita deste documento e que são recomendadas como leitura complementar.

• A summary of the international standard date and time notation
  https://www.cl.cam.ac.uk/~mgk25/iso-time.html
  
  
• Date and Time on the Internet: Timestamps
  https://datatracker.ietf.org/doc/html/rfc3339
  
  
• IETF STD 95
  https://www.rfc-editor.org/info/std95
  
  
• HTTP Usage in the Registration Data Access Protocol (RDAP)
  https://datatracker.ietf.org/doc/html/rfc7480
  
  
• Security Services for the Registration Data Access Protocol (RDAP)
  https://datatracker.ietf.org/doc/html/rfc7481
  
  
• Registration Data Access Protocol (RDAP) Query Format
  https://datatracker.ietf.org/doc/html/rfc9082
  
  
• JSON Responses for the Registration Data Access Protocol (RDAP)
  https://datatracker.ietf.org/doc/html/rfc9083
  
  
• Finding the Authoritative Registration Data (RDAP) Service
  https://datatracker.ietf.org/doc/html/rfc9224
  
  
• Inventory and Analysis of WHOIS Registration Objects
  https://datatracker.ietf.org/doc/html/rfc7485
  
  
• Registration Data Access Protocol (RDAP) Object Tagging
  https://datatracker.ietf.org/doc/html/rfc8521
  
  
• Registration Data Access Protocol (RDAP) for Digital Forensic Investigators
  https://www.digitalforensics.ch/nikkel17.pdf
  
  
• We’re still on whois? What’s holding back RDAP?
  https://blog.apnic.net/2017/08/11/2017-still-whois-whats-holding-back-rdap/
  
  
• RDAP no Registro.br
  https://registro.br/rdap/
  
  
• Sources of Abuse Contact Information for Abuse Handlers
  https://www.ripe.net/publications/docs/ripe-658
  
  
• CSIRT FAQ - Tradução do CSIRT FAQ do CERT®/CC
  https://cert.br/certcc/csirts/csirt_faq-br.html
  
  
• INOC-DBA
  https://inoc.nic.br/
  
  

11. Agradecimentos

Gostaríamos de agradecer a Lucimara Desiderá pelo desenvolvimento da versão inicial e subsequentes atualizações deste documento, e a Cristine Hoepers, Klaus Steding-Jessen, Luiz Eduardo R. Cordeiro, Miriam von Zuben e Renato Otranto Jr. pela revisão e por sugestões para o desenvolvimento deste documento.

12. Histórico de Revisões

• Versão 1.0 Versão Inicial, 09/06/2015
• Versão 1.1 Correção de erros de ortografia e de edição, publicação de dois modelos novos (cc-rat e phishing-scam) e renumeração das seções 7 e 8, 20/04/2016
• Versão 1.2 Inclusão de novo conteúdo relativo a RDAP, atualização de URLs, atualização de exemplos de WHOIS, atualização dos modelos de notificação para refletir uso de RDAP, melhoria dos modelos de DNS malicioso e phishing com pharming, adição do modelo de phishing para dispositivos móveis, revisão geral e correção de erros tipográficos, 20/03/2022
• Versão 1.3 Melhorias no texto do modelo de notificação de DNS malicioso, atualização das RFCs relativas ao padrão RDAP, atualização dos dados do APNIC e correção de erros tipográficos, 04/04/2022