Google Dorking: Guia de Google Dorks para Iniciantes (2026)

O que é Google dorking?

Google dorking é a prática de usar operadores de busca avançados para encontrar informação que um buscador indexou mas que o dono nunca pretendeu publicar. Um dork é uma dessas consultas. Em vez de perguntar ao Google do que uma página trata, você pede páginas com um tipo de arquivo específico, uma palavra específica na URL ou uma frase específica no título, e deixa os erros de configuração virem à tona.

O nome vem de Johnny Long, que começou a catalogar em 2002 as consultas que expunham sistemas sensíveis e as organizou na Google Hacking Database (GHDB) em 2004. Ele apresentou a pesquisa na Black Hat em 2004 e publicou Google Hacking for Penetration Testers em 2005. Desde 2010 a GHDB é mantida pela OffSec como parte do Exploit Database.

Aqui está a parte que os iniciantes costumam entender errado. O dorking não explora nada no Google. O Google está fazendo o trabalho dele perfeitamente: ele rastreou uma URL pública e indexou o que encontrou. A vulnerabilidade está do outro lado, onde alguém deixou a listagem de diretórios ligada, colocou um arquivo .env dentro da raiz web, ou pôs um relatório interno em um servidor sem autenticação com um link apontando para ele. O dorking só te dá uma linguagem de consulta para achar esse tipo de erro em escala.

A MITRE registra isso na tática de Reconhecimento como T1593.002, Search Engines, descrevendo como adversários usam "consultas especializadas para procurar vazamentos de informação sensível, como detalhes de rede ou credenciais". Atacantes de verdade usam isso, e é exatamente por isso que quem defende precisa conhecer a técnica.

Os operadores de busca do Google que importam

Existem dezenas de operadores circulando em posts de blog. Oito deles fazem quase todo o trabalho. Aprenda esses e você consegue montar qualquer dork de que vá precisar.

Os que o Google realmente documenta

Vale saber quais deles o Google assume oficialmente. A página oficial de refinamento de busca documenta apenas as aspas de frase exata, site:, o sinal de menos para exclusão, filetype: e os operadores de data before: e after:. Todo o resto da tabela acima não é documentado.

Não documentado não quer dizer quebrado. intitle:, inurl: e intext: funcionam há duas décadas e não dão sinal de que vão sumir. Quer dizer, sim, que o Google não te deve nada se um deles mudar de comportamento na terça que vem, o que acontece de verdade.

As variantes com prefixo merecem uma linha cada. allintitle: e allinurl: exigem que todas as palavras seguintes casem, em vez de apenas uma, o que ajuda de vez em quando mas combina mal com os outros operadores. Na prática, você vai usar intitle: duas vezes em vez de recorrer a allintitle: uma vez.

Operadores mortos em 2026

É aqui que a maioria dos guias rápidos desmorona. Se um artigo ainda lista estes, ele foi copiado e não testado:

• cache: - acabou. O Google aposentou seu cache público em fevereiro de 2024 e removeu o operador junto. O Search Liaison confirmou a remoção publicamente. Em setembro de 2024 o Google passou a incluir links para o Internet Archive nos resultados, como substituto parcial.
• link: - descontinuado em 2017. Ainda devolve alguma coisa, mas a amostra é tão filtrada que o resultado não serve para nada.
• info: - aposentado. O Google agora mostra os mesmos detalhes de página pelo painel "Sobre este resultado".
• + e ~ - ambos abandonados há anos. Use aspas para correspondência exata no lugar de +.

Quando precisar de uma cópia arquivada de uma página que já foi limpa, vá direto para a Wayback Machine. Esse hábito é mais confiável do que o cache: jamais foi, porque o arquivo guarda histórico em vez de um único instantâneo.

Combinando operadores: seus primeiros dorks de verdade

Um operador é uma busca. Três operadores formam um dork. Todo o ofício está em empilhar restrições até o ruído sumir, e o jeito mais rápido de entender isso é montar uma consulta por etapas.

Digamos que você esteja testando uma empresa e queira saber quais documentos dela estão parados no índice do Google. Comece amplo:

site:example.com

Isso traz toda página indexada do domínio, o que em uma empresa real significa milhares de resultados inúteis. Restrinja a documentos em vez de páginas web:

site:example.com filetype:pdf

Melhorou, mas um site corporativo publica folhetos e fichas técnicas de propósito. Você quer os documentos publicados por acidente, então acrescente uma frase que só aparece em documentos que alguém queria manter dentro de casa:

site:example.com filetype:pdf "internal use only"

Agora corte o subdomínio que hospeda a biblioteca pública de marketing, já que você sabe o que tem lá:

site:example.com -site:downloads.example.com filetype:pdf "internal use only"

Quatro operadores, e o conjunto de resultados saiu de milhares de páginas para uma lista que você lê em dois minutos. Essa progressão, do amplo para o estreito com uma subtração no fim, é o padrão por trás de todo dork bom.

Três padrões que valem a pena memorizar

Depois que o empilhamento faz sentido, a maioria dos dorks úteis cai em três formatos.

Listagem de diretórios. intitle:"index of" casa com o título de página que Apache e nginx geram quando a navegação de diretórios fica ligada e não existe arquivo de índice. Acrescente uma palavra-chave para mirar: intitle:"index of" "backup". Só esse dork responde por boa parte das exposições acidentais da internet, e isso já dura vinte anos.

Portais de login. inurl:admin e intitle:"login" encontram interfaces administrativas que nunca deveriam estar voltadas para a internet. Em um trabalho autorizado, isso mapeia a superfície de ataque rapidamente, e costuma revelar um painel de homologação esquecido rodando duas versões principais atrás da produção.

Mensagens de erro. Um stack trace no índice te conta o framework, às vezes a versão e, ocasionalmente, um caminho de arquivo no servidor. Buscar uma string de erro exata acompanhada de site: é assim que se encontram aplicações rodando em modo debug.

Na prática, a combinação de operadores importa menos que a palavra-chave que você entrega a ela. Qualquer um roda filetype:xlsx. Quem encontra alguma coisa rodou filetype:xlsx com uma palavra que só aparece nos modelos internos do alvo, e tirou essa palavra de uma página perfeitamente comum do site do próprio alvo.

Um guia rápido de Google dorks em que dá para confiar

Todo dork abaixo usa apenas operadores com funcionamento confirmado em 2026. Leia a coluna do meio antes de copiar a da esquerda, porque entender por que um dork funciona é o que permite escrever os seus.

Dois hábitos vão te poupar tempo. Primeiro, rode o mesmo dork no Bing e no DuckDuckGo quando o Google voltar vazio, porque os três buscadores indexam cantos diferentes da web e o Bing ainda aceita ip: para busca reversa por endereço IP. Segundo, espere um CAPTCHA se disparar vinte dorks seguidos. Isso é o Google limitando sua taxa de requisições, não te bloqueando, e ir mais devagar resolve. Ferramentas que despejam centenas de consultas por minuto colocam seu IP em uma pausa bem mais longa.

A Google Hacking Database

A Google Hacking Database é um índice público e categorizado de consultas de busca que expõem informação sensível ou sistemas vulneráveis. Ela existe desde 2004 e vive no Exploit-DB, onde cada entrada é etiquetada, datada e creditada a quem a submeteu.

As entradas são agrupadas pelo que encontram, e os nomes das categorias dizem muito sobre como os sistemas falham:

• Files Containing Passwords, Files Containing Usernames, Files Containing Juicy Info
• Sensitive Directories, Vulnerable Files, Vulnerable Servers
• Pages Containing Login Portals, Various Online Devices
• Error Messages, Web Server Detection, Footholds
• Advisories and Vulnerabilities, Network or Vulnerability Data, Sensitive Online Shopping Info

Use a GHDB como fonte de ideias, não como uma lista para executar. Muitas entradas antigas miram software que não existe mais, e o Google discretamente parou de casar parte da sintaxe. O valor está no padrão: leia dez entradas de "Vulnerable Servers" e você vai começar a perceber quais strings um determinado produto sempre coloca nos títulos, um conhecimento que dá para apontar para aquilo que você realmente está testando.

Uma opinião forte, já que alguém precisa dizer: ignore as listas de "os 1000 melhores Google dorks". São cópias de cópias da GHDB com os operadores mortos deixados lá dentro, e percorrer uma delas não te ensina nada além de colar texto. Oito operadores e o raciocínio por trás deles te levam mais longe que mil consultas que você não escreveu.

Google dorking em CTFs e no reconhecimento de bug bounty

Para quem joga CTF, o dorking aparece em dois lugares. Desafios de OSINT te entregam um nome, um usuário ou uma foto e esperam que você descubra o resto: uma consulta site: bem mirada nas plataformas onde as pessoas vazam coisas sobre si mesmas ganha de qualquer ferramenta. Desafios de web às vezes escondem uma dica ou uma versão antiga de uma página completamente fora da máquina do desafio, e a Wayback Machine mais um dork site: te levam até lá.

É no bug bounty que o reconhecimento por dorking dá dinheiro de verdade. O fluxo que funciona é este:

1. Leia o escopo do programa e anote todo domínio e todo curinga que você tem permissão de tocar.
2. Rode site:*.target.com -www para enumerar de graça os subdomínios que o Google já conhece, antes de resolver um único registro DNS.
3. Cace os tipos de arquivo que ninguém publica de propósito: filetype:env, filetype:sql, filetype:log, filetype:bak.
4. Vasculhe as plataformas de código: site:github.com "target.com" junto com palavras como api_key, token ou os nomes de projetos internos da empresa.
5. Veja o que uma versão antiga do site expunha e depois confirme se o caminho ainda está no ar.

Repare no que essa lista não inclui: encostar no alvo. Tudo acima consulta um terceiro, e é por isso que o dorking é classificado como reconhecimento passivo e por isso é seguro rodá-lo antes de a janela de teste abrir. No instante em que você busca uma dessas URLs diretamente, ou começa a forçar caminhos com uma ferramenta como o Gobuster, você entrou em teste ativo e as regras mudam por completo.

O dorking se combina naturalmente com o resto de um kit de reconhecimento, em vez de substituí-lo. Nossa seleção de ferramentas OSINT gratuitas mostra onde a enumeração de subdomínios, a consulta a vazamentos e a extração de metadados assumem depois que o Google entregou tudo o que tinha.

Como verificar o que o Google sabe sobre o seu site

A metade defensiva dessa habilidade leva dez minutos e é o item mais valioso deste artigo para quem administra um site. Rode isto no seu próprio domínio agora mesmo:

site:yourdomain.com intitle:"index of"
site:yourdomain.com filetype:env
site:yourdomain.com filetype:sql OR filetype:bak OR filetype:log
site:yourdomain.com inurl:admin OR inurl:login
site:yourdomain.com "confidential" OR "internal use only"

Tudo o que voltar já é público. Foi rastreado, indexado e servido a quem pedisse, e apagar o arquivo hoje não muda quem o leu ontem.

O DHS, o FBI e o NCTC publicaram um boletim conjunto sobre isso em julho de 2014, intitulado "Malicious Cyber Actors Use Advanced Search Techniques". Ele documenta um caso de outubro de 2013 em que atacantes usaram dorking para localizar sites rodando uma versão vulnerável de um software de fórum, e então comprometeram 35.000 sites e criaram contas de administrador neles. A recomendação do próprio boletim era reduzir o que vai para a internet, fazer autoauditoria com a GHDB e remover conteúdo indexado pelo Search Console.

A armadilha do robots.txt

O instinto é adicionar o caminho sensível ao robots.txt. Não faça isso. São dois problemas, e ambos são piores do que aquilo que você queria corrigir.

Primeiro, o robots.txt controla o rastreamento, não a indexação. Uma URL bloqueada ainda pode aparecer nos resultados do Google se qualquer coisa, em qualquer lugar, apontar para ela, porque o Google nunca precisou rastrear a página para saber que ela existe. A própria documentação do Google diz de forma direta que o robots.txt não é um mecanismo para manter uma página fora dos resultados de busca.

Segundo, o robots.txt é um arquivo público. A primeiríssima requisição de um hacker em um alvo novo é /robots.txt, justamente porque os administradores listam ali, prestativos, seus diretórios mais sensíveis. Você desenhou o mapa do tesouro e o deixou na porta de entrada.

O que fazer no lugar: coloque uma tag noindex ou um cabeçalho X-Robots-Tag nas páginas que precisam ficar fora do índice, use a ferramenta de remoção do Search Console para o que já foi indexado, e ponha autenticação de verdade na frente de qualquer coisa realmente sensível. A listagem de diretórios deve estar desligada em todo servidor web de produção, e um arquivo .env simplesmente nunca deveria ser alcançável a partir de uma raiz web.

Considerações legais e éticas

O Google dorking fica em uma zona genuinamente cinzenta, e a resposta honesta é que a consulta está tudo bem e o que você faz depois pode não estar. O dork consulta o Google. Agir sobre o resultado toca o sistema de outra pessoa.

Onde você está claramente em dia

• Auditar domínios que você possui ou administra
• Trabalhos cobertos por uma autorização assinada que nomeie o domínio no escopo
• Programas de bug bounty, dentro do escopo e das regras que o programa publica
• Competições de CTF e labs de treino feitos para prática
• Pesquisa de segurança em que você reporta os achados sem baixar nem redistribuir os dados

Onde as pessoas se metem em encrenca

• Baixar dados pessoais expostos "só para conferir se são reais"
• Entrar em um portal com credenciais achadas em um arquivo indexado, mesmo uma vez, mesmo para confirmar que funcionam
• Publicar um dork que aponta para uma organização específica ainda sem correção antes de ela ter corrigido
• Automatizar centenas de consultas contra um domínio fora de qualquer autorização

Se você encontrar algo exposto que não é seu, o caminho certo é a divulgação responsável: contate a organização, descreva o que está público e como você achou, não toque nos dados e dê tempo para corrigirem. Para situar o reconhecimento dentro de uma metodologia estruturada, o Web Security Testing Guide da OWASP documenta a fase de coleta de informação em detalhe.

Perguntas frequentes